Apache NetBeans

Friday November 01, 2019

[ANNOUNCE] Apache NetBeans 11.2 Released

The Apache NetBeans team is pleased to announce the release of Apache NetBeans 11.2. Apache NetBeans is a full IDE for Java SE, Java EE, PHP and JavaScript development with some Groovy language support.

Apache NetBeans 11.2 is the second Apache NetBeans release outside the Apache Incubator and the second release of the new quarterly release cycle. The LTS release of the Apache NetBeans 11 cycle is Apache NetBeans 11.0. The 11.2 release has not been as heavily tested as the LTS release. Use 11.2 to access the latest features and to provide feedback for the next LTS release, scheduled for April 2020.

New & noteworthy features of the 11.2 release:

https://netbeans.apache.org/download/nb112/index.html

Downloads:

https://netbeans.apache.org/download/nb112/nb112.html

Feel free to share the good news!

Wednesday September 11, 2019

NetBeans at Oracle Code One 2019

An Apache NetBeans schedule for those going to Oracle Code One 2019 next week!

Saturday, September 14

19:00 Hang out in the Thirsty Bear in Howard Street

Monday, September 16

  • Why You Should Be Coding with the NetBeans IDE [BOF1321]
    Mark Stephens, Developer, IDRsolutions
    Ethan Price, Developer, IDRsolutions
    02:30 PM - 03:15 PM | Moscone South - Room 305
  • Java IDE Wars [DEV1375]
    Ken Fogel, Teacher, Dawson College
    Scott Selikoff, Software Developer, Selikoff Solutions, LLC
    Jeanne Boyarsky, Developer, CodeRanch
    04:00 PM - 04:45 PM | Moscone South - Room 304
  • Hacking the NetBeans IDE [BOF1338]
    Mark Stephens, IDR Solutions
    06:00 PM - 06:45 PM | Moscone South - Room 309
  • Hacking the NetBeans Profiler [BOF4170]
    Ryan Cuprak, Formulation Applications R&D Development Senior Manager, Dassault Systemes
    06:00 PM - 06:45 PM | Moscone South - Room 305

Tuesday, September 17

  • Getting Started with Deep Learning for Enterprise Java Developers [DEV2126]
    Zoran Sevarac, Associate Professor, University of Belgrade, Faculty of Organisational Sciences
    Suyash Joshi, Developer Marketing Director, Oracle
    12:30 PM - 01:15 PM | Moscone South - Room 308
  • Testing on Oracle Autonomous Database with Homomorphic Encryption, Using NetBeans and Java - BYOL [HOL3196]
    Simon Bain, Founder & CTO, ShieldIO
    12:30 PM - 02:30 PM | Moscone West - Room 3024C

Wednesday, September 18

  • Apache NetBeans: Its Status and Future [DEV2506]
    Geertjan Wielenga, Product Manager, Oracle
    Mark Stephens, Developer, IDRsolutions
    Ethan Price, Developer, IDRsolutions
    06:00 PM - 06:45 PM | Moscone South - Room 206

Thursday, September 19

  • Testing on Oracle Autonomous Database with Homomorphic Encryption, Using NetBeans and Java - BYOL [HOL3196]
    Simon Bain, Founder & CTO, ShieldIO
    09:00 AM - 11:00 AM | Moscone West - Room 3024C
  • 19:00 Hang out in the Thirsty Bear in Howard Street

Sunday August 25, 2019

What to do with JavaFX and OpenJFX in Apache NetBeans?

If Apache NetBeans runs on JDK 8, a range of Ant-based JavaFX sample applications are available in NetBeans to help you get started and learn about JavaFX. However, if NetBeans does not run on JDK 8, the available Ant-based JavaFX samples don't work (can't be created) but there's no point in working on fixing that since from JDK 11 onwards JavaFX is no longer part of the JDK and Maven/Gradle-based OpenJFX samples are obvious candidates for integration into NetBeans instead.

However, how should that be handled in NetBeans? Before Apache NetBeans 11.1, there was no integration with OpenJFX. Only JavaFX projects and samples were built into NetBeans, which led to a great deal of confusion since when someone sets up an environment from scratch today, they're unlikely to have installed JDK 8. Much more likely, they'll have JDK 11 or 12 and then those JavaFX projects and samples in NetBeans cannot be used, i.e., when you try to create those samples, while running NetBeans on anything other than JDK 8, you're simply told in the wizard that you have the wrong JDK. And then you somehow need to find out that the best thing to do next is use the OpenJFX documentation to set up the OpenJFX samples in NetBeans.

That is suboptimal and so Gluon integrated their two sample applications into Apache NetBeans 11.1, i.e., in the most recent release:

https://github.com/apache/netbeans/tree/master/javafx/openjfx.samples

That is a step forward but still suboptimal, as explained here by Jaroslav Tulach:

https://github.com/apache/netbeans/pull/1241#issuecomment-491357016

That entire new module is not needed. Literally, all that needs to be done is that this file needs to be updated with two new template registrations:

https://github.com/apache/netbeans/blob/master/java/maven/src/org/netbeans/modules/maven/newproject/MavenWizardIterator.java

And, literally, this is all that needs to be added there, since the two OpenJFX samples are on Maven Central and as pointed out above, "NetBeans has a nice support for creating wizards over Maven archetypes."

@TemplateRegistration(folder = ArchetypeWizards.TEMPLATE_FOLDER, 
position = 925, 
displayName = "#LBL_Maven_FXML_Archetype", 
iconBase = "org/netbeans/modules/maven/resources/jaricon.png", 
description = "javafx.html")
@Messages("LBL_Maven_FXML_Archetype=FXML JavaFX Maven Archetype")
public static WizardDescriptor.InstantiatingIterator<?> openJFXFML() {
    return ArchetypeWizards.definedArchetype("org.openjfx", "javafx-archetype-fxml", "0.0.2", null, LBL_Maven_FXML_Archetype());
}

@TemplateRegistration(folder = ArchetypeWizards.TEMPLATE_FOLDER, 
position = 926, 
displayName = "#LBL_Maven_Simple_Archetype", 
iconBase = "org/netbeans/modules/maven/resources/jaricon.png", 
description = "javafx.html")
@Messages("LBL_Maven_Simple_Archetype=Simple JavaFX Maven Archetype")
public static WizardDescriptor.InstantiatingIterator<?> openJFXSimple() {
    return ArchetypeWizards.definedArchetype("org.openjfx", "javafx-archetype-simple", "0.0.2", null, LBL_Maven_Simple_Archetype());
}

That literally is all that is needed to be added to the Java source file above, instead of having a completely new module, which doesn't integrate as neatly as the above with the Apache NetBeans infrastructure. (And this is a small tip for anyone else wanting to make their Maven archetypes available to NetBeans: the above is literally all you need to do.)

However, the fundamental question remains: how do we notify users of Apache NetBeans that they should be using OpenJFX and not JavaFX? Maybe we should simply remove all JavaFX projects and samples, however that would be unfortunate for anyone using JDK 8. Or maybe the solution is to create a category named "Legacy" in the New Project dialog and then put all JavaFX projects and samples there, so that it's clear that they're not recommended, while still having them available for JDK 8 users?

Saturday August 24, 2019

Simplified Apache NetBeans Welcome Screen

To simplify the Welcome Screen and, in particular, replace all links to netbeans.org with netbeans.apache.org, I have created this issue and pull request:

https://issues.apache.org/jira/browse/NETBEANS-3020

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

All references to netbeans.org are replaced with equivalents at netbeans.apache.org and the News column, which pointed to netbeans.org, is removed from the tab below, while the Blogs column is renamed to News, since newsworthy items now come from here, i.e., from this blog:

Also, the Featured Demo on the first tab is removed, best to have as few links to external places as possible, i.e., help reduce potential points of failure, especially here where having that demo in the page doesn't add all that much while removing it reduces the need for external URL calls that could cause problems and slow things down.

Saturday August 17, 2019

LSP Client demo - (ba)sh language server

Below is a scenario by Jan Lahoda, the creator of LSP integration for Apache NetBeans, for how to integrate the bash language server with Apache NetBeans, including syntax highlighting.

Setting Up

  1. Install npm (and node.js). On Ubuntu, e.g., do "apt install npm", though something different will be needed on Mac OS X.

  2. Create a directory in which we are going to work, have a terminal opened in that directory.

  3. Install the bash-language-server:

    npm install bash-language-server

    On Mac OSX:

    npm install bash-language-server --unsafe-perm

    This will install the server into the current directory.

  4. Try the bash server:

    ./node_modules/bash-language-server/bin/main.js --help

    You should see something like this:

    Usage:
      bash-language-server start
      bash-language-server -h | --help
      bash-language-server -v | --version
  5. Create a NetBeans module. Create a File Type (Module Development/File Type), mime type: text/sh, file extension: sh

Syntax Coloring via TextMate

  1. Download the TextMate grammar file here, and put it alongside the newly created DataObject:

    https://raw.githubusercontent.com/microsoft/vscode/master/extensions/shellscript/syntaxes/shell-unix-bash.tmLanguage.json

  2. Add "TextMate Lexer" as a dependency of the module.

  3. Into the DataObject add this annotation:

    @GrammarRegistration(grammar="shell-unix-bash.tmLanguage.json", mimeType="text/sh")

    GrammarRegistration is:

    import org.netbeans.modules.textmate.lexer.api.GrammarRegistration;

This should lead to syntax highlighted source for .sh bash files taken from the TextMate grammar file.

Language Support via the Language Server

Next, we need to add language support using the language server.

  1. Add "LSP Client" and "MIME Lookup API" as dependencies of the module.

  2. Create a new class, ShellClient, in the module, put this into it, (replacing "<path-to-bash-language-server>" with the absolute path to "node_modules/bash-language-server"):

    import java.io.IOException;
    import org.netbeans.api.editor.mimelookup.MimeRegistration;
    import org.netbeans.modules.lsp.client.spi.LanguageServerProvider;
    import org.openide.util.Exceptions;
    import org.openide.util.Lookup;
    
    @MimeRegistration(mimeType="text/sh", service=LanguageServerProvider.class)
    public class ShellClient implements LanguageServerProvider {
    
       @Override
       public LanguageServerDescription startServer(Lookup lkp) {
           try {
               Process p = new ProcessBuilder("<path-to-bash-language-server>/bin/main.js", "start").start();
               return LanguageServerDescription.create(p.getInputStream(), p.getOutputStream(), p);
           } catch (IOException ex) {
               Exceptions.printStackTrace(ex);
               return null;
           }
       }
    
    }

    You may need to explicitly call node in the above code, i.e., as follows:

    Process p = new ProcessBuilder(
            "/usr/local/bin/node", 
            "<path-to-bash-language-server>/bin/main.js", 
            "start").start();
  3. Build and start the module.

Caveat: the language server is started only for files that are inside a project, so create (any) new project, and inside the project, put a shell file. E.g. copy "bin/netbeans" as "test.sh" into the project. Open it in the editor - there should be syntax highlighting, Navigator, and code completion should show something, etc.

Tuesday August 06, 2019

Why Does Apache NetBeans Need Its Own Parsers?

A question was asked on the Apache NetBeans mailing list: "I was just curious about the theoretical aspect of parsing. Isn't there a unified parsing API, using ANTLR/lex/yacc which can parse any language given a grammar for it? Why do we use a different parsing implementation (like the Graal JS parser in this instance) when a unified approach will help us support lots of languages easily?"

Tim Boudreau, involved in NetBeans from its earliest hours, responds, in the thread linked above:

First, in an IDE, you are *never* just "parsing". You are doing *a lot* with the results of the parse. An IDE doesn't have to just parse one file; it must also understand the context of the project that file lives in; how it relates to other files and those files interdependencies; multiple versions of languages; and the fact that the results of a parse do not map cleanly to a bunch of stuff an IDE would show you that would be useful. For example, say the caret is in a java method, and you want to find all other methods that call the one you're in and show the user a list of them. The amount of work that has to happen to answer that question is very, very large. To do that quickly enough to be useful, you need to do it ahead of time and have a bunch of indexing and caching software behind the scenes (all of which must be adapted to whatever the parser provides) so you can look it up when you need it. In short, a parser is kind of like a toilet seat by itself. You don't want to use it without a whole lot of plumbing attached to it.

Second, while there are tools like ANTLR (version 4 of which is awesome, by the way), there is still a lot of code you have to write to interact with the results of a parse to do something useful beyond syntax coloring in an IDE. One of my side projects is tooling for NetBeans that *do* let you take an ANTLR grammar and auto generate a lot of the features a language plugin should have. Even with that almost completely declarative, you wind up needing a lot of code. One of the languages I'm testing it with is a simple language called YASL which lets you define javascript-like schemas with validation constraints (e.g., this field is a string, but it must be at least 7 characters and match this pattern; this is an integer number but it must be > 1 and less than 1000 - that sort of thing). All the parsing goodness in the world won't write hints that notice that, say, the maximum is less than the minimum in an integer constraint and offer to swap them. Someone has to write that by hand.

Third, in an IDE with a 20 year history, a lot of parser generating technologies have come and gone - javacc, javacup, ANTLR, and good old hand-written lexers and parsers. Unifying them all would be an enormous amount of work, would break a lot of code that works just fine, and the end result would be - stuff we've already got, that already works, just with one-parser-generator-to-rule-them-all underneath. Other than prettiness, I don't know what problem that solves.

So, all of this is to say: We use different parsing implementations because parsing is just a tiny piece of supporting a language, so it wouldn't make the hard parts easier enough to be worth it. And there will be new cool parser-generating technologies that come along, and it's good to be able to use them, rather than be married to one-parser-generator-to-rule-them-all and have this conversation again, when they come along.

Monday July 22, 2019

[ANNOUNCE] Apache NetBeans 11.1 Released

The Apache NetBeans team is pleased to announce the release of Apache NetBeans 11.1. Apache NetBeans is a full IDE for Java SE, Java EE, PHP and JavaScript development with some Groovy language support.

Apache NetBeans 11.1 is the first Apache NetBeans release outside the Apache Incubator and the first release of the new quarterly release cycle. The LTS release of the Apache NetBeans 11 cycle is Apache NetBeans 11.0. The 11.1 release has not been as heavily tested as the LTS release. Use 11.1 to access the latest features and to provide feedback for the next LTS release, scheduled for April 2020.

New & noteworthy features of the 11.1 release:

https://netbeans.apache.org/download/nb111/index.html

Downloads:

https://netbeans.apache.org/download/nb111/nb111.html

Feel free to share the good news!

Monday June 10, 2019

Apache NetBeans, OpenJFX, and AdoptOpenJDK

Check out a great series of articles on a killer combination, by Chris Luff—Apache NetBeans, OpenJFX, and AdoptOpenJDK.

In part one you see how to get a modular JavaFX application built and running from NetBeans. In part two, you look at generating, from Maven, a runtime to execute the application. In part 3, you learn about the distribution of the new application.

Here are the three parts:

Thursday April 25, 2019

[ANNOUNCE] Apache NetBeans Has Graduated!

We have graduated from the Apache Incubator and we are now a top level Apache project at The Apache Software Foundation (ASF).

"Being part of the ASF means that NetBeans is now not only free and Open Source software: it is also, uniquely, and for the first time, part of a foundation specifically focused on enabling open governance," said Geertjan Wielenga, Vice President of Apache NetBeans. "Every contributor to the project now has equal say over the roadmap and direction of NetBeans. That is a new and historic step and the community has been ready for this for a very long time. Thanks to the strong stewardship of NetBeans in Sun Microsystems and Oracle, Apache NetBeans is now ready for the next phase in its development and we welcome everyone to participate as equals as we move forward."

The above is from the official Apache press release, all of which can be read here:

https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces51

Friday April 05, 2019

[ANNOUNCE] Apache NetBeans (incubating) 11.0 Released

The Apache NetBeans team is proud to announce the release of Apache NetBeans (incubating) 11.0.

Apache NetBeans (incubating) 11.0 constitutes all clusters in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE, Java EE, PHP, JavaScript and Groovy features of Apache NetBeans.

In short, Apache NetBeans (incubating) 11.0 is a full IDE for Java SE, Java EE, PHP and JavaScript development with some Groovy language support.

Read more on our download page:

https://netbeans.apache.org/download/nb110/nb110.html

New & Noteworthy features of the 11.0 Release:

https://netbeans.apache.org/download/nb110/index.html

Friday February 01, 2019

Restructuring of Project Templates in Apache NetBeans

There's been lots of discussion in the Apache NetBeans community about how best to express the fact that Apache Maven and Gradle are more modern choices to be aware of than Apache Ant, while at the same time not implying that there's anything wrong with using Apache Ant.

Here's what we seem to have reached consensus around, i.e., move all Ant-based project templates into a separate Ant-specific folder, while putting the other two build systems higher and therefore more prominently in the list:

With the above, someone is less likely to simply go to the no-longer-existing Java category and then end up with an Ant-based project, without thinking about it. By default, the user of Apache NetBeans is now encouraged to consider Apache Maven and Gradle first. The old Ant-related categories are still there, so as not to confuse anyone completely, just structured within a lower ranked "Java with Ant" category. The above also solves the discussion re "Java EE", i.e., here the idea, from discussions, is to name the category "Java Enterprise".

At startup, all categories are closed, i.e., none is more prominent initially than any other.

An objection one could have is that, if you're a complete Java newbie, you won't know what Maven, Gradle, or Ant are. Well, that has always been the case and NetBeans has artificially hidden that choice by having a category simply named "Java", which then resulted in everyone ending up with Ant-based projects. To turn that around and have a category simply named "Java" that results in Maven-based projects is probably not right either, i.e., a careful balance needs to be struck.

Hoping that all factions in this lengthy discussion are relatively satisfied with this approach. :-)

Issue: https://issues.apache.org/jira/browse/NETBEANS-2040

Pull request: https://github.com/apache/incubator-netbeans/pull/1115

Monday January 28, 2019

Enterprise Cluster Integrated into Apache NetBeans

Hurray, the 'enterprise' cluster, constituting all the modules in Apache NetBeans GitHub that provide features for Java/Jakarta EE development, provided in the 2nd Oracle donation of NetBeans to Apache, has been integrated into the daily builds.

Now, for the first time, out of the box, you'll have the support that was part of NetBeans IDE 8.2 for Java EE development directly available in Apache NetBeans, that is, without you needing to install any plugins.

However, aside from the point that this means we do not yet have Java EE 8 support, since 8.2 did not (could not, because of being released some time prior to Java EE 8) have support for Java EE 8, another question now presents itself—whether we really want to have two categories in the New Project dialog, one named "Java EE" and the other named "Java Web", as shown below, with the former containing project types relating to EJBs and EARs, which are not (should not) be very current anymore, as shown below in the screenshots.

My suggestion would be to either relabel the above to "Modern Java EE" and "Vintage Java EE". (I like the word "Vintage", which I've learned about from JUnit, i.e., that's how they refer to JUnit 4.) Once there is Java EE 8 support, we could use the name "Jakarta" instead of "Modern Java EE". Or, maybe the EJB and EAR support should simply be removed?

Sunday January 27, 2019

Junit 5, Apache Ant, and Apache NetBeans

Junit 5 is, architecturally, so different to previous versions, that it should really be called Jupiter, instead. However, this is not a problem when you're using Maven, since Maven resolves all transitive dependencies for you, and is supported in that way from Apache NetBeans 10 onwards. Not so with Apache Ant, of course, where you need to set each and every JAR you need on a classpath of one form or another.

That is not a pretty picture in the end, when compared to JUnit 4, where you had just that JAR, plus Hamcrest. With JUnit 5, you need, in addition to junit-jupiter-api, junit-jupiter-params, and junit-jupiter-engine, to also declare the transitive dependency apiguardian-api, while in the case of Apache Ant, you need to deal with the JUnitLauncher, if you want to make use of the new junitlauncher Ant task, in addition to four other JARs, which need to be on Ant's classpath, as explained here.

An alternative approach is to use org.junit.platform.console.ConsoleLauncher, as shown here, which looks like this in my build.xml, i.e., it is named test, so that it will run automatically at the end of the test run when the Test Project action is invoked:

<target name="test" depends="compile-test,-pre-test-run">
    <java dir="${work.dir}" 
          classpath="${run.test.classpath}"  
          classname="org.junit.platform.console.ConsoleLauncher">
        <arg value="--scan-classpath"/>
        <arg line="--reports-dir build/test/results"/>
    </java>
    <junitreport todir="build/test/results">
        <fileset dir="build/test/results">
            <include name="TEST-*.xml"/>
        </fileset>
        <report format="frames" todir="build/test/results/html"/>
    </junitreport>
</target>

The above means that the JUnit tasks set by default in the build-impl.xml file will simply fail silently, since I don't have JUnit 4 on my classpath. At the end of the process, the above will be run, org.junit.platform.console.ConsoleLauncher will be found on my classpath, and then the JUnit 5 tests will be run.

What is the advantage of the above over using JUnitLauncher? Well, JUnitLauncher has requirements relating to Ant's path, which has advantages too, of course, i.e., simply set everything up once (which can also be done inside Apache NetBeans, in the Ant tab in the Options window). But, for right now, I'd prefer to work with just one path, i.e., the application's path.

Another downside is that, so far, the above solution doesn't integrate with the Test Results window, though it does produce some nice reports via the junitreport task above, in the build folder.

The key problem seems to me to be that the JUnit Ant task no longer exists in JUnit 5, which was for Ant-based projects the basis of the integration with the Test Results window in Apache NetBeans. If the JUnit task could continue to be used, in whatever way, that would solve a lot of the problems, though the question of the many JARs needed on the classpath would remain. Maybe library providers should reach out to tools providers when putting these kinds of new solutions together, since the only reason that JUnit 5 now works with Maven in Apache NetBeans is that Surefire is used, i.e., in the case of Maven the completely new approach JUnit has taken can simply be avoided there. Here is some relevant discussion in Apache NetBeans GitHub, and the Launcher API looks interesting.

Probably the best solution for Ant users in Apache NetBeans would be to be able to continue to use JUnit 4, rather than JUnit 5, since the latter is a total nightmare to set up in the context of Ant, as described above. In the world of JUnit, "vintage" is the cool name they have for "legacy", and if you're using Ant at all, you're probably best described as "vintage" and hence only having support for JUnit 4 is not a big deal for you. However, not sure at all how that would work, we'd need to investigate how/if when JUnit tests are added to Maven projects, JUnit 5 tests and dependencies would be set, while when adding JUnit tests to Ant projects JUnit 4 tests and dependencies would be set.

Thursday December 27, 2018

[ANNOUNCE] Apache NetBeans (incubating) 10.0 Released

The Apache NetBeans team is proud to announce the release of Apache NetBeans (incubating) 10.0.

Apache NetBeans (incubating) 10.0 constitutes all but the enterprise cluster in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE, PHP, JavaScript and Groovy features of Apache NetBeans.

In short, Apache NetBeans (incubating) 10.0 is a full IDE for Java SE, PHP and JavaScript development with some Groovy language support.

Read more on our download page:

https://netbeans.apache.org/download/nb100/nb100.html

New & Noteworthy features of the 10.0 Release:

https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+10.0+New+and+Noteworthy

See the below for the donation status of features that have not been donated or included in Apache builds yet, i.e., are not part of Apache NetBeans (incubating) 10.0, e.g., features for working with C/C++, and more:

https://cwiki.apache.org/confluence/display/NETBEANS/Apache+Transition

Work is being done on bringing netbeans.org to Apache. In the meantime, refer to the below for all details related to Apache NetBeans:

https://netbeans.apache.org/

Wednesday November 07, 2018

Calendar

Search

Hot Blogs (today's hits)

Tag Cloud

Categories

Feeds

Links

Navigation