Apache NetBeansApache NetBeans Blog
The Apache NetBeans team is pleased to announce that Apache NetBeans 21 was released on February 1, 2024.
What’s in the Apache NetBeans 21 release:
With thanks to 24 contributors, including 3 who have contributed for the first time. Thank you!
Downloads:
See our release schedule:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, Martin, Geertjan
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 20 was released on December 1, 2023.
What’s in the Apache NetBeans 20 release:
With thanks to 26 contributors, including 6 who have contributed for the first time. Thank you!
Downloads:
See our release schedule:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, Martin, Geertjan
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 19 was released on September 1, 2023.
What’s in the Apache NetBeans 19 release:
With thanks to 31 contributors, including 5 who have contributed for the first time. Thank you!
Downloads:
See our release schedule:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, Martin, Geertjan
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 18 was released on May 30, 2023.
What’s in the Apache NetBeans 18 release:
With thanks to 31 contributors, including 5 who have contributed for the first time. Thank you!
Downloads:
See our release schedule:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, Martin, Geertjan
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 17 was released on February 21, 2023.
What’s in the Apache NetBeans 17 release:
With thanks to 36 contributors, including 7 who have contributed for the first time. Thank you!
Downloads:
See our release schedule:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, Martin, Geertjan
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 16 was released on November 30, 2022 (though there’s been a delay in announcing the release).
What’s in the Apache NetBeans 16 release:
With thanks to 26 contributors, including some who have contributed for the first time. Thank you!
Downloads:
See our release schedule:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, Martin, Geertjan
on behalf of Apache NetBeans PMC
As part of being involved in Apache, I got the opportunity yesterday to go to Brussels to attend the European Commission’s EC Open Source Workshops - Computing and Sustainability.
Me and The EU
Aside from my many years of involvement in the context of open source, in particular in the context of Apache NetBeans and the Friends of OpenJDK, I recently completed my LL.M Masters of Law at the University of Amsterdam in European Union Law (25 years after completing my LL.B Bachelor of Law in South Africa) especially because, aside from the academic side of it, I wanted to finally understand how the EU actually works, with all its institutions, etc, and, though I can’t say I really have a full grasp on it all yet (I doubt anyone really does), it was quite moving to be at one of the key pillars of that institution yesterday.
To describe all the discussions that took place would be impossible, since I could only physically attend a few of them because many happened in parallel, it was great to meet several people I knew already from real life and virtually, such as Simon Phipps, Dirk van Gulik, Roman Shaposhnik, and Jarek Potiuk, as well as many other new people, there were just too many, from all different organizations, NGOs, local administrations, governments, etc, from within the EU and beyond.
Each workshop consisted of a panel that kicked off discussions, with participants in the room being able to participate, ending with voting on the most important topics to carry forward and recommend to the European Commission.
Themes
A key theme in the workshops I was in was the disconnect and misunderstandings between the public sector and industries on one side and open source on the other.
There have been many advances made in the sense that open source is now everywhere, though it is not everywhere in a balanced way nor supported and sustainable to the extent that is could or should be.
I keep seeing an image of the lone maintainer of an open source project in front of me, late at night, hacking away at code all for free that large enterprises and companies around the world simply consume and sell as part of their products. Not only is that an insecure and unsustainable situation there are clear moral and ethical aspects connected to that as well.
Carrot and Stick
Clearly there was quite some support for compelling the industry to make public its dependencies on open source, i.e., be compelled to list on their websites which open source technologies they’re using, how they are contributing back to those projects (and other open source projects), be compelled to push their changes upstream, and expose/explain what they are doing to enable their developers, in terms of time and money, to contribute to open source projects that those companies have integrated in one way or another.
A separate idea, not following the legal compliance road, would be some kind of fair trade accreditation scheme whereby a company would need to comply with certain standards, e.g., the above list for example, in order to get accredited with some level of FOSS fair trade certification, which would be a helpful way for FOSS-aware developers to make the right choices when looking for employment.
There is simply so much work in IT nowadays that, in fact, companies are now being interviewed by developers rather than the other way around, and one of the questions asked by a developer would be: "What is your FOSS Fair Trade Accreditation level?"
I’d love to be in a world where that question is asked and, though we’d need to be wary of bad actors and have some kind of mechanism for accreditation, and though it may not solve everything (that would be an unfair standard for any solution), it would certainly be a step forward.
A group of Java engineers gathered in a pub in Prague last night to celebrate many years of their engagement in NetBeans, all having worked in Sun Microsystems or Oracle or both, continuing into the Apache world where NetBeans is now found.
This will not be the last of such gatherings, anyone involved in NetBeans over the years is more than welcome to attend or set up similar get togethers, ideally in a pub, which is also where NetBeans started.
The Apache NetBeans team is pleased to announce that Apache NetBeans 15 was released on August 31, 2022 (though there’s been a delay in announcing the release).
What’s in the Apache NetBeans 15 release:
With thanks to 33 contributors, including some who have contributed for the first time. Thank you!
Downloads:
See our release schedule:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, Geertjan
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 14 was released on June 9, 2022 (though there’s been a delay in announcing the release).
What’s in the Apache NetBeans 14 release:
Note it’s the first time we’re doing a generated changelog like the above, next time it will be even better, we’ll work on generating different sections and highlights, to make it easier to read through.
Downloads:
See our release schedule:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, Geertjan
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 13 is released today on March 4, 2022. Apache NetBeans is a full IDE for Java SE, Java EE, PHP, JavaScript, HTML5 and more, including some support for Groovy and C/C++.
Our schedule is publicly available here:
New & noteworthy features of the 13 release:
Downloads:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil, Eric, and Geertjan
Release Manager for Apache NetBeans 13
on behalf of Apache NetBeans PMC
Log4j v2 is not a direct component of Apache NetBeans or a dependency of any current component. The Apache NetBeans PMC has studied earlier versions to see if there is any other risk. We do not believe any vulnerability in Log4j v1 is exploitable in Apache NetBeans IDE.
Apache NetBeans Platform developers, i.e., those creating applications on top of Apache NetBeans, should make their own assessment.
If you are aware of any issue, please follow the guidelines at https://www.apache.org/security.
The Apache NetBeans team is pleased to announce that Apache NetBeans 12.6 was released on November 29th 2021. Apache NetBeans is a full IDE for Java SE, Java EE, PHP, JavaScript, HTML5 and more, including some support for Groovy and C/C++.
Our schedule is publicly available here:
New & noteworthy features of the 12.6 release:
Downloads:
Feel free to share the good news!
Thanks everyone, and best wishes,
Neil and Geertjan
Release Manager for Apache NetBeans 12.6
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 12.5 was released on September 13th 2021 [1]. Apache NetBeans is a full IDE for Java SE, Java EE, PHP, JavaScript, HTML5 and more, including some support for Groovy and C/C++.
Apache NetBeans 12.5 is a quarterly feature update. The LTS release of the current cycle is Apache NetBeans 12.0. The 12.5 release has not been as heavily tested as the LTS release. Our schedule is publicly available here:
New & noteworthy features of the 12.5 release:
Downloads:
Feel free to share the good news!
Thanks everyone, and best wishes,
Eric
Release Manager for Apache NetBeans 12.5
on behalf of Apache NetBeans PMC
The Apache NetBeans team is pleased to announce that Apache NetBeans 12.4 was released on May 19th 2021 [1]. Apache NetBeans is a full IDE for Java SE, Java EE, PHP, JavaScript, HTML5 and more, including some support for Groovy and C/C++.
Apache NetBeans 12.4 is a quarterly feature update. The LTS release of the current cycle is Apache NetBeans 12.0. The 12.4 release has not been as heavily tested as the LTS release. Our schedule is publicly available here:
New & noteworthy features of the 12.4 release:
Downloads:
Feel free to share the good news!
Thanks everyone, and best wishes,
Geertjan and Neil
Release Managers for Apache NetBeans 12.4
on behalf of Apache NetBeans PMC
"We have updated the JEP with a few changes to the "Issue Warnings" section [1], summarized as follows: If the Java runtime is started without setting the system property 'java.security.manager' then a custom Security Manager can be installed dynamically by calling System::setSecurityManager, just as in Java 16. No UnsupportedOperationException will be thrown. This call will, however, issue a warning message explaining that the Security Manager is deprecated and will be removed in a future release. We plan to change the default value of the 'java.security.manager' system property to "disallow" in the next release, i.e., Java 18. That will cause System::setSecurityManager to throw an UnsupportedOperationException in Java 18. With these changes, the process of deprecating and eventually removing the Security Manager will be consistent with our treatment of past breaking changes such as, e.g., the strong encapsulation of internal APIs. Maintainers of libraries and applications will be given fair warning before any existing code is broken."
Following on from part 1 on this topic, JEP 411 has recently been updated with a "Future Work" section, amongst other changes. From the Apache NetBeans perspective, this is a welcome shift in the wording of this JEP. It is great that the owner and reviewers of JEP 411 recognize the special needs of complex, multi protection domain applications, such as IDEs. Such applications inherently run "less trusted" code, such as 3rd party JavaBean libraries in design time, and the ability to prevent such libraries to "System::exit" (at least) voluntarily is essential for preventing an IDE from unexpectedly closing.
From the Apache NetBeans point of view, however, it is still very concerning to note the sudden incompatible change in SecurityManager behavior and the rapid pace it is proposed to be implemented. Deprecating SecurityManager now and giving time to the overall Java ecosystem to adapt to such a change is acceptable, however, changing the JVM’s behavior incompatibly by requiring additional command line switches is disturbing.
In particular, no existing version of Apache NetBeans is going to launch with the JEP 411 changes. Unless one starts the JDK with a special property, it is not going to be possible to use the SecurityManager. Specifically, NETBEANS-5689 will prevent the IDE from starting. Should a user provide the proposed "-Djava.security.manager=allow" property, then the launch fails as well due to interaction with the Equinox framework, as shown in link;NETBEANS-5703.
Let’s face it, there is no known workaround. Apache NetBeans will not launch on JDK 17, i.e., the next LTS of Java.
Ideally JEP 411 would actually do what it says and deprecate only, rather than incompatibly changing the JVM’s behavior. The Java community should be given the next few years to adjust to the change and release updated versions of libraries (like Equinox) that are ready for the deprecation. Then applications should be updated (like NetBeans) to use such libraries. Only then should the incompatible mode be turned on, if at all.
Should the authors of JEP 411 take their shift in understanding the special need of IDEs & other complex multi protection domain applications seriously, they would prevent all sudden incompatibilities related to JEP 411 when deprecating SecurityManager.
In JEP 411, announcing the deprecation of java.lang.SecurityManager, one would hope that the use cases for which SecurityManager exists will be replaced by more modern APIs, before it is removed from the OpenJDK. Below is a partial list of use cases for which the SecurityManager is used by Apache NetBeans:
-
checkExit. Ability to prevent accidental invocations of System.exit is very important for any application that deals with other unknown libraries (as IDEs do). JDK-8199704 is filled for this, but there is no proposal for an API yet, so it is impossible to tell how the API will cover this use case. The current API allows, for example, to partially simulate the effect of System.exit, while it also allows to provide a user-understandable message when a real exit is rejected.
-
Watching file system access. In various places, both in production code and in tests, SecurityManager is used as a tool to receive notifications of file reading or writing. This is especially important in integration tests, to guarantee that code is never accessing disk, unless absolutely necessary (for performance reasons, among others). In principle, the WatchService could be used for these use cases. However, the WatchService is not guaranteed to work (e.g., due to OS restrictions), it cannot detect read-only access, and requires subscription to individual Paths. SecurityManager provides a more reliable way to monitor all filesystem access done by Java code.
-
Warning or prevention of use of obsolete and/or dangerous idioms. The SecurityManager is used to warn about the use of obsolete System properties (via checkPropertyAccess) and the use of`sun.misc.Unsafe unsupported APIs via checkMemberAccess.
-
Identifying User Application Windows. The showWindowWithoutWarningBanner permission is used to track which windows belong to which user’s custom application (so that they can be closed when call to
System.exitis intercepted). -
Misc. There are also restrictions on potentially dangerous code, which are probably less important and are covered by Reinier’s e-mail. There are also few (probably) obsoleted workarounds.
Summary
Apache NetBeans doesn’t use java.lang.SecurityManager to guarantee security, but rather to gain additional insight into the JVM’s behavior.
Without having such insights, the IDE’s user experience would be severely affected.
It is to be hoped that replacement APIs are being designed and that they will be provided for evaluation before JEP-411 is integrated.
The Apache NetBeans team is pleased to announce that Apache NetBeans 12.3 was released on March 3rd 2021. Apache NetBeans is a full IDE for Java SE, Java EE, PHP, JavaScript, HTML5 and more, including some support for Groovy and C/C++.
Apache NetBeans 12.3 is the first quarterly feature update in 2021. The LTS release of the current cycle is Apache NetBeans 12.0. The 12.3 release has not been as heavily tested as the LTS release. Our schedule is publicly available here:
New & noteworthy features of the 12.3 release:
Downloads:
Feel free to share the good news!
The Apache NetBeans team is pleased to announce that Apache NetBeans 12.2 was released on December 5th 2020. Apache NetBeans is a full IDE for Java SE, Java EE, PHP, JavaScript, HTML5 and more, including some support for Groovy and (new) C/C++.
Apache NetBeans 12.2 is the second quarterly feature update in the NetBeans 12 cycle. The LTS release of the current cycle is Apache NetBeans 12.0. The 12.2 release has not been as heavily tested as the LTS release. Use 12.2 to access the latest features and to provide feedback for the next LTS release, scheduled for mid-2021.
New & noteworthy features of the 12.2 release:
Downloads:
Feel free to share the good news!
The Apache NetBeans team is pleased to announce that Apache NetBeans 12.1 was released on Sept 1st 2020. Apache NetBeans is a full IDE for Java SE, Java EE, PHP, JavaScript, HTML5 and more, including some support for Groovy and (new) C/C++.
Apache NetBeans 12.1 is the first quarterly feature update in the NetBeans 12 cycle. The LTS release of the current cycle is Apache NetBeans 12.0. The 12.1 release has not been as heavily tested as the LTS release. Use 12.1 to access the latest features and to provide feedback for the next LTS release, scheduled for mid-2021.
New & noteworthy features of the 12.1 release:
Downloads:
Feel free to share the good news!
Apache NetBeans 12.0 adds support for the latest Java language features, integrates new code donations from Oracle for Java Web development, enhances its best of breed Apache Maven tooling, brings multiple enhancements for users of Gradle, includes built-in features for Payara and WildFly for the first time, introduces new out of the box templates for JavaFX, upgrades and extends its PHP editor, provides new dark look and feel options, and includes a wide range of fixes.
All features provided by Apache NetBeans are supported out of the box, without additional plugins needing to be installed, and all for free. Apache NetBeans 12.0 is the first LTS release of NetBeans as a top level Apache project.
We would like to thank all contributors, the community, and the Apache Software Foundation for the great co-operation and enthusiasm enabling this complex and exciting project to continue to inspire and be of use to developers all over the world.
New & noteworthy features of the 12.0 release:
Downloads:
Feel free to share the good news!
Researchers at GitHub have identified 26 projects on GitHub that have been infected by malware[1]. The initial point of infection is undetermined and all activity with the malware has been shut down. The malware relied on project templates generated by Apache NetBeans using an older customized Apache Ant-based build system that has been in limited use since 2006. This does not impact users of other build systems like Apache Maven or Gradle or even most Apache Ant users. The majority of Apache NetBeans projects leverage native build tool integrations that are shared with continuous integration systems. With over 44 million repositories hosted on GitHub[2], the scope of these 26 projects looks isolated, these projects have been set to private, and their owners contacted, while GitHub has not had reason to contact the NetBeans community about this, indicating that this has no significant impact on the NetBeans community.
Note: Software Supply Chain attacks are not unique to any IDE and the NetBeans community will continue to monitor the threat landscape to keep developers safe and aware. Be aware[3] that any build system that you use when developing applications, with any IDE or build system, can be infiltrated by malware. Always make sure that the files you check into your versioning system are your own or that you know where they come from and what they do.
Apache NetBeans 12.0 will be released once many people:
-
Download Apache NetBeans 12.0 Beta 4: removed
-
Try it out. Here is an overview of the newest features, though incomplete: removed
-
Fill in this very quick survey: removed
The Apache NetBeans team is pleased to announce the release of Apache NetBeans 11.3. Apache NetBeans is a full IDE for Java SE, Java EE, PHP and JavaScript development with some Groovy language support.
Apache NetBeans 11.3 is the third Apache NetBeans release outside the Apache Incubator and the third release of the new quarterly release cycle. The LTS release of the Apache NetBeans 11 cycle is Apache NetBeans 11.0. The 11.3 release has not been as heavily tested as the LTS release. Use 11.3 to access the latest features and to provide feedback for the next LTS release, scheduled for April 2020.
New & noteworthy features of the 11.3 release:
Downloads:
Feel free to share the good news!
Eric Barboni, our Release Manager of 11.3, produced Apache NetBeans 11.3-beta2 build the other day. It is available for testing!
Those using the Snap distribution and would like to give it a try:
sudo snap refresh --channel=edge netbeansThis release is identical to 11.2 except for backported fixes for:
NETBEANS-3257 Fixed issue on refactoring rename of java method (and potentially other nb-javac issues)
NETBEANS-3335 Enhance robustness of HTML Lexer - enter key doesn’t work in certain files
NETBEANS-3290 Fix common.xml causing layer build problems in RCP applications
Use the Plugin Manager under the Tools menu to update 11.2 to 11.2 Update 1.
One month has passed since NetBeans 11.2 had been released. There are 82 new PR-s made it to the master branch so far. We usually have a, not necessary intentional, "theme" for each release. I’d say the theme is for 11.3 is: "Remove the Rust".
Our code and libraries spent long time in the transit. Many of our modules were still compiling against Java 1.6 and/or used ancient versions of third party libraries. 11.3 improved a lot on this front and there are still many PR are in the queue to carry that on. Without trying to be complete, here is a small list of changes what’s coming:
-
Jgit Library Update
-
ASM, PostgreSQL, JUnit5 and Other Library Updates.
-
PHP Fixes
-
HTML Lexer Stability Improvements
-
JSF 2.3 Support
-
Gradle Tooling 6.0
-
Several Cleanups, Remove Compile Warnings
On the UI Side:
-
Return of Dark Metal and Dark Nimbus Look and Feel
-
Experimental support for Flatlaf Look and Feel
On Gradle Side:
-
Test Output is Channeled Back to the IDE
-
Added Project Reload Action
-
Elephant Icons Finally Replace the old Ones
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:
Downloads:
Feel free to share the good news!
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
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:
That is a step forward but still suboptimal, as explained here by Jaroslav Tulach:
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:
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?
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:
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.
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
-
Install npm (and node.js). On Ubuntu, e.g., do "apt install npm", though something different will be needed on Mac OS X.
-
Create a directory in which we are going to work, have a terminal opened in that directory.
-
Install the bash-language-server:
npm install bash-language-serverOn Mac OSX:
npm install bash-language-server --unsafe-permThis will install the server into the current directory.
-
Try the bash server:
./node_modules/bash-language-server/bin/main.js --helpYou should see something like this:
Usage: bash-language-server start bash-language-server -h | --help bash-language-server -v | --version -
Create a NetBeans module. Create a File Type (Module Development/File Type), mime type: text/sh, file extension: sh
Syntax Coloring via TextMate
-
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
-
Add "TextMate Lexer" as a dependency of the module.
-
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.
-
Add "LSP Client" and "MIME Lookup API" as dependencies of the module.
-
Create a new class, ShellClient, in the module, put this into it, (replacing " " 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("/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", "/bin/main.js", "start").start(); -
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.
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.
Hi all. Today, we will briefly show you about PHP7.4 support which will be available in the next NetBeans version i.e. NetBeans 11.2.
First of all, I strongly hope that new features are tested by PHP users before NetBeans 11.2 is released because there should be bugs. Definitely, we need your help!
If you are interested in them, please test it. You can download a dev version here.
Then, we could merge new changes quickly thanks to our committer Tomas Mysik. Thanks a lot for your review, Tomas!
PHP 7.4 Support
To enable it, you have to set PHP 7.4 as the PHP version of your PHP project. (Right-click your project node, click Project Properties.)
NetBeans provides support for the new syntaxes for PHP 7.4.
New Hints
Suggestion for converting a simple closure to an arrow function
Suggestion for using combined assignment operators
Of course, code completion, formatting, go to declaration, and mark occurrence features for the above syntaxes should also be fixed.
That’s all for today. As always, please test it. You can download a development version from Jenkins Build. If you find some issues or enhancements, please report them to JIRA with your exact steps to reproduce them. (Components: php - Editor). Thanks.
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:
Downloads:
Feel free to share the good news!
Check out a great series of articles on a killer combination, by Chris Lufg—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:
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:
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.
New & noteworthy features of the 11.0 release:
Downloads:
There’s been lots of discussion in the Apache NetBeans community about how best to express the fact that Apache Maven and Apache 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 Apache 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. :-)
Pull request: https://github.com/apache/incubator-netbeans/pull/1115
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?
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.
Enhanced scripting tutorial has just become part of Apache NetBeans documentation. It contains various examples showing how to communicate from Java with JavaScript, Python and other languages. The following topics are covered:
While the primary use-case for this enhanced scripting API is to simplify usage of scripting languages in NetBeans based applications, the API itself is standalone and can be used outside of NetBeans in any project. We are working on making it available in the Maven central repository.
Read more in the online tutorial.
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:
New & Noteworthy features of the 10.0 Release:
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:
Work is being done on bringing netbeans.org to Apache. In the meantime, refer to the below for all details related to Apache NetBeans:
Apache NetBeans 10vc3 is the third voting candidate of Apache NetBeans (incubating) 10 and has been created for purposes of NetCAT activities:
Build artifacts: download removed
Binaries: download removed
Sources: download removed
Please try 10vc3 and fill out the Community Acceptance Survey:
survey link removed
Watch a helpful YouTube clip here: https://www.youtube.com/watch?v=G7_OPJ6grvM
During Oracle Open World 2018, Apache NetBeans was awarded a Duke’s Choice Award, recognizing its innovation and the hard and dedicated work involved in moving NetBeans from Oracle to Apache.
A crowd of Apache NetBeans community members received the award on the stage from Georges Saab, VP of the Java Platform at Oracle.
Schedule:
-
Saturday, Oct 20, 19:00 p.m. | Thirsty Bear, 661 Howard Street
Informal hangout (i.e., buy your own beer) with Apache NetBeans PPMC, committers, and community!
-
Sunday, Oct 21, 11:00 a.m. | Bike Ride
-
Monday, Oct 22, 1:30 p.m. - 2:15 p.m. | Moscone West - Room 2016
Title: Machine Learning for Software Developers in 45 Minutes [DEV5090]
Speakers: Zoran Sevarac, Frank Greco
-
Monday, Oct 22, 1:30 p.m. - 2:15 p.m. | Moscone West - Room 2022
Title: Back from the Ashes: eFX/JavaFX Applications Made Simple [DEV5406]
Speakers: Sven Reimers, Florian Vogler
-
Monday, Oct 22, 2:30 p.m. - 3:15 p.m. | Moscone West - Room 2018
Title: Exploring Java Heap Dumps [DEV5262]
Speakers: Ryan Cuprak
-
Monday, Oct 22, 7:30 p.m. - 8:15 p.m. | Moscone West - Room 2005
Title: Deep Learning for Application Performance Optimization [BOF4967]
Speakers: Zoran Sevarac
-
Monday, Oct 22, 8:30 p.m. - 9:15 p.m. | Moscone West - Room 2009
Title: Hacking the NetBeans IDE [BOF4760]
Speakers: Mark Stephens, Developer, Bethan Palmer
-
Tuesday, Oct 23, 7:30 p.m. - 8:15 p.m. | Moscone West - Room 2010
Title: Writing Better Code (Faster) in the Apache NetBeans IDE [BOF4759]
Speakers: Mark Stephens, Developer, Bethan Palmer
-
Tuesday, Oct 23, 7:30 p.m. - 8:15 p.m. | Moscone West - Room 2014
Title: Got a Gig Teaching Java? You Should Be Using Apache NetBeans in the Classroom [BOF4820]
Speakers: Kenneth Fogel, Instructor, Concordia University
-
Wednesday, Oct 24, 2:30 p.m. - 3:15 p.m. | Moscone West - Room 2016
Title: Bridging Swing and JavaFX on an Enterprise Scale [DEV6080]
Speakers: Sven Reimers, José Pereda
-
Wednesday, Oct 24, 9:00 a.m. - 9:45 a.m. | Moscone West - Room 2010
Title: Java Debugging Tips [DEV4512]
Speakers: Martin Skarsaune
-
Wednesday, Oct 24, 2:45 p.m. - 4:45 p.m. | Moscone West - Room 2001A (HOL)
Title: Lambda Programming Laboratory - BYOL [HOL6006]
Speakers: Jeff Dinkins, Stuart Marks, Maurice Naftalin, José Paumard
-
Thursday, Oct 25, 09:00 AM - 11:00 AM | Moscone West - Overlook 2A (HOL)
Title: Jakarta EE Hands-on Lab - BYOL [HOL4852]
Speakers: David Heffelfinger, Bob Larsen
Did you know that the first stage of Language Server Protocol (LSP) support will be included in Apache NetBeans 10?
See this PR for details, with instructions for how to use it.
Some screenshots for Kotlin support via LSP:
A lot more work needs to be done, of course, some of which is here, you’re welcome to join in:
Hi all. Today, we will briefly show you about PHP7.3 support which will be available in the next NetBeans version i.e. NetBeans 10.
First of all, I strongly hope that new features are tested by PHP users before NetBeans 10 is released because there should be bugs. Definitely, need your help! If you are interested in them, just test them. You can download a dev version here.
PHP 7.3 Support
To enable it, you have to set PHP 7.3 as the PHP version of your PHP project.
NetBeans provides support for the new three syntaxes.
PHP 7.1, 7.2 and more PHP features
The other PHP features for NetBeans 10 are here.
We have also implemented PHP7.1, 7.2, new hints, new code foldings and more.
That’s all for today. As always, please test it. You can download a development version from Jenkins Build.
If you find some issues or enhancements, please report them to JIRA with your exact steps to reproduce them. (Components: php - Editor). Thanks.
Hi all. Today, we will show you about PHPStan integration which will be available in the next NetBeans version i.e. NetBeans 10 as a new code analysis feature.
If you have already used other code analysis features(e.g. Code Sniffer), you should be able to use this with similar way soon.
Options
First of all, let’s set the Options (Tools > Options > PHP > Code Analysis > PHPStan). You can set a script path, a configuration file path and a level. At least you have to set the PHPStan script path to "PHPStan". If you don’t set "Configuration" path, the configuration file of project root directory would be used.
Inspect project/directory/file
Then, let’s inspect a project/direcoty/file using PHPStan. Please click "Source > Inspect…". The inspect dialog is shown.
Please choose "Scope" which you would like to inspect and PHPStan as "Configuration". The files are inspected when you click the "inspect" button. Finally, The results are shown in the inspector window after the inspection is done.
That’s all for today. As always, please test it. You can download a development version from Jenkins Build. If you find some issues or enhancements, please report them to JIRA (Components: php - Code). Thanks.
The third of a series of informal virtual meetups took place today, focused specifically on why/how/when to move netbeans.org to Apache.
The audio of the meeting is available here and takes about 53 minutes:
Clicking on the image above will load the video and send data from and to Google
Screenshot of what we saw of each other, partly:
Related links:
I’m a big fan of NetBeans, and a team-lead of 2pm.tech crew, a group of independent developers from Russia. For about the last five years, we have been using NetBeans in all of our projects, from "hardcore C embedded systems" to "Grails web-apps", and as a result we’ve also been hacking NetBeans a little.
As of 2018, there are now 11 developers in the team. Currently, half of us work with Grails apps, despite the poor Grails support in NetBeans at the moment. We’re continuing to work with NetBeans due to it simplicity, small footprint, and design. If the NetBeans community would dig up the Groovy/Grails support, lots of developers will switch to NetBeans I think, and also I’ll be very happy, too. :-)
One of coolest things we’ve created lately is the Crew Look & Feel plugin, which we hadn’t released to the public yet and now we think the time has come. It’s not too complicated, but a nice little add-in to have, maybe it’ll be useful for other users too. Here it is on the Plugin Portal:
Click to enlarge the images below, to get a feel for the new plugin that provides our look and feel:
NetBeans is my favorite IDE and Apache is one of my technological icons. So, I’m very happy for NetBeans to be migrating to Apache. Apache does not always give you a sweet design, though it does always provide nice UNIX-like tools, and I love it. I hope Apache will make NetBeans not only better, but the best IDE for all Java-based technologies. :-)
Hi all. Today, we will show you some new features which will be available in the next NetBeans version, maybe (NetBeans 10? NOTE: we cannot promise anything about release contents at the moment).
First of all, if you would like to try new features, please build NetBeans yourself.
git clone git@github.com:apache/incubator-netbeans.git
cd incubator-netbeans
ant -Dcluster.config=full
(or ant -Dcluster.config=php)You can find the start-up files in the nbbuild/netbeans/bin directory if the build succeeds. So please run it.
Debugger: Conditional breakpoints
You can stop the debugger if the context matches your condition. i.e. If the condition is true, the debugger stops on the breakpoint, otherwise, it does not stop there.
I assume that you have already done the settings for debugging. (please see: HowToConfigureXDebug) If xdebug doesn’t work, please ask someone via Apache NetBeans mailing lists. (Please don’t ask here.)
Just in my case(Ubuntu 18.04):
sudo apt install php-xdebug
sudo vim /etc/php/7.2/mods-available/xdebug.ini
# Change to the following
zend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.idekey="netbeans-xdebug"Let’s try running with a sample code(index.php):
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title></title>
</head>
<body>
<?php
$array = ["foo", "bar", "baz", "qux"];
foreach ($array as $value) {
echo $value;
}
?>
</body>
</html>
Step 2: Show the Breakpoint Properties dialog
To show it, please right-click the breakpoint, then please click .
The second of a series of informal virtual meetups took place today.
The audio of the meeting is available here and takes about 45 minutes:
Clicking on the image above will load the video and send data from and to Google
Sign up to the next virtual meetups here:
link removed
Today an article was published on InfoQ describing the current state and progress of Apache NetBeans.
Click to read the start of it here:
Go here to read it all:
The first of a series of informal virtual meetups took place today.
The audio of the meeting is available here and takes about an hour:
Clicking on the image above will load the video and send data from and to Google
The Apache NetBeans team is proud to announce the release of Apache NetBeans (incubating) 9.0.
Apache NetBeans (incubating) 9.0 constitutes all the modules 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-related features of Apache NetBeans. In short, Apache NetBeans (incubating) 9.0 is a full IDE for Java SE development.
Read more on our download page:
New & Noteworthy features of the 9.0 Release:
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) 9.0, e.g., features for working with Java EE, JavaScript, PHP, C/C++, and more:
Also see:
What’s Happened to My Favorite NetBeans Plugins?
Work is being done on bringing netbeans.org to Apache. In the meantime, refer to the below for all details related to Apache NetBeans:
Disclaimer: Apache NetBeans is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
Not long after you start up Apache NetBeans (incubating) 9.0 on top of JDK 8, after accepting the license agreement and handling import settings, you’re confronted with this dialog:
What does that mean? And why, when you start up Apache NetBeans (incubating) 9.0 on top of JDK 9 or above, do you see the following, instead:
| The above appears in a balloon popup in the bottom right the first time you start up Apache NetBeans (incubating) 9.0 on JDK 9 or above. If you miss out on seeing or responding to the message, go to Window | IDE Tools | Notifications anytime afterwards and you’ll have another opportunity to install it: |
Let’s start by looking at the question, what is "nb-javac"? Well, "nb-javac", which is a patched version of "javac", i.e., the Java compiler, has long been part of NetBeans, providing a highly tuned Java compiler specifically for the Java editor in NetBeans, and wasn’t part of the donation of NetBeans to Apache since, of course, the Java compiler (or a fork thereof) cannot be part of the donation. That’s because Oracle is not donating Java to Apache, instead, it is donating NetBeans. The Java compiler belongs to the JDK which is licensed to Oracle.
Separate from Oracle’s obvious understandable unwillingness to donate a Java compiler fork to Apache, or anyone else, Apache would have a problem with a fork of the Java compiler being distributed from Apache since the Java compiler is LGPL licensed.
In short, neither Oracle nor Apache want the Java compiler to be part of NetBeans in Apache. Yet, NetBeans gains a lot from the patched Java compiler, as explained below:
Also see this reference for details on the situation:
However, using model APIs added in JDK 9, Apache NetBeans can make use of the Java compiler directly from the JDK, as explained here:
So, as can be seen, from Apache NetBeans running on JDK 9 and onwards, you have a choice: either use the Java compiler from the JDK, which means you’re not benefiting from a number of enhancements especially added for NetBeans over many years in the patched Java compiler, or you need to explicitly add the patched Java compiler, since it is provided by Oracle and its licensing is such that you need to take responsibility for installing it yourself. On the other hand, if you’re using Apache NetBeans with JDK 8, the choice is simpler, i.e., you need to install nb-javac, otherwise you will not be able to use Java in Apache NetBeans.
It’s not an ideal situation. On the other hand, if someone has a better solution, please feel free to propose that solution and also consider providing a pull request too!
So, you start up Apache NetBeans (incubating) 9.0 and… you find that when you go to the New Project wizard, or when you try to open your projects, that there’s no support for your JavaScript, PHP, Groovy, enterprise Java (i.e., Java EE or, as it is known now, Jakarta EE), and C/C++ projects.
What’s the reason for that and what can be done?
Well, Apache NetBeans (incubating) 9.0 is specifically focused on Java SE only. Why? Because NetBeans is extremely large (it will be by far the largest project in Apache, once everything has been donated), which is because it has existed for over 20 years and provides support for a very wide range of technologies. Since so many files all needed to be audited before they could be donated to Apache, the decision was made to donate NetBeans in pieces, i.e., not everything at the same time because that would have taken much too long.
And since NetBeans is modular, doing an incremental donation was not difficult to architect. The first donation focused specifically on the underlying core, i.e., the NetBeans Platform (e.g., the module system, window system, menubar, etc etc) and, to enable the result of the first donation to be usable for general users and not just NetBeans Platform developers, the various Java SE features were included too, e.g., Java project templates, Java editor, and new Java features such as support for Jigsaw, JLink, and JShell.
The above is what Apache NetBeans (incubating) 9.0 consists of. In the meantime, the second donation has been completed, i.e., Oracle has audited and donated all the modules for features providing support for JavaScript, PHP, Groovy, and enterprise Java (i.e., Java EE or, as it is known now, Jakarta EE). These features are on a separate branch in the Apache NetBeans Git repo. They will be integrated, i.e., relicensed to Apache, after Apache NetBeans (incubating) 9.0 is released. After that, the next set of modules that is being audited prior to donation are related to C/C++.
So, does that mean that all the features that are not integrated into Apache NetBeans (incubating) 9.0 cannot be used? No, it does not. Go to Tools | Plugins in Apache NetBeans (incubating) 9.0 and, in the Settings tab, register the NetBeans IDE 8.2 update center:
http://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz
Then go to the Available Plugins tab and you’ll see all the plugins for NetBeans IDE 8.2., and search for the word "Kit", which will give you bundles of modules, for higher-level features such as C/C++, JavaScript, Groovy, PHP, and enterprise Java (i.e., Java EE or, as it is known now, Jakarta EE).
Though note that none of these features have been tested with Apache NetBeans (incubating) 9.0, they should work, in most cases. If not, don’t panic. Just sign up to the Apache NetBeans mailing lists, as explained at netbeans.apache.org, and start a new thread where you’ll highlight some problem you’ve encountered, after which someone will help you or you’ll be advised to create a new issue in Apache NetBeans Issuezilla.
Where is all this documented, how can anyone know what will be donated in which order, etc? Easy, go here, to the end of this page:
We’re currently running two processes, both of which it would be great if everyone would participate in — and in fact it’s really important that everyone does these two things:
-
Vote in the PPMC thread:
link removed
Doing the above means more than putting a +1, it means downloading the sources, building them, looking at keys, etc, as described above.
-
Fill out the Community Acceptance survey, which is focused on the functionality (versus the sources, which is what the PPMC thread is about), which takes about 5 minutes:
link removed
The Community Acceptance Survey runs until Sunday the 22nd of July. Issues found in the meantime will hopefully not be critical and not require a new voting candidate, but we’ll need to see how things go and nothing can be guaranteed here of course — i.e., someone could find a blocker of some kind during the community acceptance survey process.
Hopefully, nothing going wrong and everything going well, we’ll then be at a point to start the IPMC vote thread on the 23rd and, if everything goes well, release Apache NetBeans (incubating) 9.0 at the beginning of August.
After that we’ll work on the 2nd donation, relicensing it, moving it into master etc.
Last Saturday (June 30, 2018) I was invited to COFAN (Conférence au Faso sur le Numérique) to present tips for building enterprise Java applications. COFAN is a conference divided into multiple sessions on a variety of technologies. It was started last year and the second tour has been taking place since May and it is sponsored by the government of Burkina Faso.
I was given the opportunity to talk about enterprise Java in general and to show how NetBeans can be a great tool to develop strong and professional Java enterprise applications.
A room filled with an attentive audience was very enthusiastic. They were also satisfied by the answers to their questions, while some decided to continue using NetBeans, with others promising to start working with it for the first time!
Pictures of the event are below:
Hurray! The 2nd Oracle donation of NetBeans to the Apache Software Foundation, constituting 1.5M lines of code, providing tools for enterprise Java, JavaScript, PHP, Groovy, and more, has now landed on a branch of Apache NetBeans Git
The session outlining 10 tips for large corporate projects moving to Apache, with NetBeans as an illustrative example, presented at FossBack '18, is now available on YouTube:
Clicking on the image above will load the video and send data from and to Google
The full report on the session and NetBeans attendance is here: blog foss backstage
Great news: the process of completing the 2nd donation is now done and Oracle has made available a ZIP file constituting the 2nd donation. Oracle donated around 4,000,000 lines of code in the 1st donation last year and has now completed the 2nd donation constituting around 1,500,000 lines of code. This donation constitutes the modules of NetBeans dealing with enterprise Java, JavaScript, PHP, Groovy, as well as miscellaneous features applicable to Mobile and Web development.
We will continue to wrap up the final release of Apache NetBeans (incubating) 9.0, which will be focused on Java SE only. After that, or at least separate from that process, we will start relicensing the new code, i.e., from the 2nd donation, once it is in Apache NetBeans Git. Right now, it is a ZIP file, it needs to be moved to Apache NetBeans Git, and we need to do that in the right way, and figure out what the right way is.
This is a significant step forward in the transition of NetBeans from Oracle to Apache.
Yesterday I attended FOSS Backstage in Berlin. FOSS Backstage is a "conference on everything governance, collaboration, legal & economics within the scope of FOSS". I went there to present my session, based on the Apache NetBeans experiences of the past two years or so, entitled 10 Tips for Moving Large Corporate Projects to Apache. I also went because I knew that several people from the Apache Software Foundation who have been instrumental in the transition of NetBeans to Apache would also be there and I thought it was time to put some faces to the many new names that we’ve been confronted with during the transition process!
The event began for me with a wonderful speakers dinner, where I met three of the absolute key Apache people involved in the Apache NetBeans project — Emmanuel Lecharny, Bertrand Delacretaz, and Mark Struberg. Here we are, literally about 5 minutes after meeting, discussing the current status of the transition process (click the image below to increase size):
Bertrand and Mark are two of the Apache NetBeans mentors, while Emmanuel was a mentor during the beginning phase of the transition. Both Bertrand and Emmanuel were involved really in the pre-start phase of the donation, with many thanks to Emmanuel Hugonnet who introduced us, after a very nice and long conversation some years ago in Athens!
During the event, I also met several others who I have seen on Apache mailing lists — Justin McLean, Shane Curcuru, and Jim Jagielski. Really amazing to meet all these names in person — and not to forget, I also met Mark Thomas, who is the Apache VP for Brand Management, i.e., who we need to work with for the brand/domain donation, and Malcolm Bain, a lawyer specialising in ICT law, based in Barcelona, with a special focus on Open Source Projects. I also spoke with Kevin A. McGrail, who is Apache VP Fundraising, who later sent me this very nice and welcome message: "Did I hear you correct and you wanted to talk about how I can help NetBeans with sponsorship?" Yes, you did, Kevin!
What really struck me is how positive everyone at Apache is about the Apache NetBeans project. Everyone mentioned how great and active the Apache NetBeans community is, i.e., active mailing lists, several discussion threads, voting in new PPMC members, and of course also doing releases already, with everyone positive and committed to the project. I realized, especially as I was doing my presentation, when I was talking about the history of NetBeans, that the reason why Apache NetBeans is going so well in many respects is because we’ve been working on our community from the very beginning. I.e., even while NetBeans was part of commercial entities (i.e., Sun and Oracle), we had an army of volunteers all over the world, organized in structures such as NetCAT (i.e., volunteer testers), and the NetBeans Dream Team (i.e., volunteer evangelists), while we’ve also been organizing NetBeans Days all over the world for several years, i.e., we’ve come to Apache with a ready-made community, whereas for the majority of other projects coming to Apache the reason that they’re coming to Apache is because they don’t yet have a community and are looking to Apache to provide the infrastructure for doing so.
Also, really crucially, we’ve spent years educating developers everywhere about the NetBeans APIs, the NetBeans source structure, etc. That’s been massively impactful now that we’re in Apache, since those who are most active right now are those that have been involved with NetBeans for around 20 years or so. In short, there are definitely advantages to being a large corporate project in terms of transitioning to Apache — just like NetBeans, you may take a long time to get all your code across (because the donating company needs to spend time auditing and cleaning the code etc), though on the other hand you’ll potentially be bringing a massive amount of existing knowledge and a vibrant community along with you.
In short, it was great to be at FOSS Backstage and I am sure more and more Apache NetBeans community members will be submitting sessions to similar Apache events around the world and sharing their experiences, too.
The Apache NetBeans team is proud to announce the release of Apache NetBeans (incubating) 9.0 RC1.
Apache NetBeans (incubating) 9.0 RC1 constitutes all the modules in the 'release90' branch of the Apache NetBeans Git repo (https://github.com/apache/incubator-netbeans), which together provide the NetBeans Platform (i.e., the underlying application framework), which was released as Apache NetBeans 9.0 Alpha (incubating), as well as all the modules that provide the Java SE-related features of Apache NetBeans. In short, Apache NetBeans (incubating) 9.0 RC1 is a full IDE for Java SE development.
Download not available
Details on Apache NetBeans (incubating) 9.0 RC1, including a list of open issues to be resolved prior to the final release:
What must be done for the final version of Apache NetBeans (incubating) 9.0 to be released?
-
The items in the link above need to be fixed, e.g, new splash screen needs to be integrated.
-
Cherry picking of pull requests merged into 'main' for 'release90' branch.
-
Put together rc2 release, sanity test it via NetCAT, and publish it.
-
Community Acceptance survey.
-
Start Apache voting for the final release, incorporating input from the Community Acceptance survey.
-
Release 9.0, which will be an IDE for Java SE development only, the other features have not been donated yet by Oracle and are being audited and processed and be part of subsequent releases of Apache NetBeans.
Take note of the Apache NetBeans release criteria:
FYI, see the below for the donation status of features that have not been donated to Apache yet, e.g., features for working with Java EE, JavaScript, PHP, C/C++, and more:
Work is being done on bringing netbeans.org to Apache. We already have our Apache site set up, here:
On behalf of the Apache NetBeans PPMC
Geertjan
After a discussion and voting process on the Apache NetBeans (incubating) dev and user mailing lists… we have a new logo! Here it is:
The Apache NetBeans team is proud to announce the release of Apache NetBeans (incubating) 9.0 Beta.
Apache NetBeans 9.0 Beta (incubating) constitutes all the modules in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), which was released as Apache NetBeans 9.0 Alpha (incubating), as well as all the modules that provide the Java SE-related features of Apache NetBeans. In short, Apache NetBeans 9.0 Beta (incubating) is a full IDE for Java SE development.
See the below for the donation status of features that have not been donated to Apache yet, e.g., features for working with Java EE, JavaScript, PHP, C/C++, and more:
Note: Apache NetBeans (incubating) 9.0 Beta is primarily focused on IP clearance. Its functionality has not been tested — the NetCAT (NetBeans Community Acceptance Testing) process will begin now that Apache NetBeans (incubating) 9.0 Beta has been released. Watch this space for upcoming announcements about NetCAT. When NetCAT completes, we will vote on the final release of Apache NetBeans (incubating) 9.0.
Details on Apache NetBeans (incubating) 9.0 Beta:
Download not available
Work is being done on bringing netbeans.org to Apache. In the meantime, refer to the below for all details related to Apache NetBeans:
On behalf of the Apache NetBeans PPMC
Geertjan
Watch this quick session, with a number of Apache NetBeans team members, to learn about the status of the process at Apache NetBeans (incubating):
Clicking on the image above will load the video and send data from and to Google
As part of the Apache NetBeans IP clearance we are combing through all the code and dependencies.
One interesting thing we bumped into was that the jsch 0.1.54 binary JAR we are using has a different hash (and size) than the binary JAR from Maven Central.
The old hash is 0D7D8ABA0D11E8CD2F775F47CD3A6CFBF2837DA4, the new one is DA3584329A263616E277E15462B387ADDD1B208D.
The binaries are 278,612 bytes vs 280,515 bytes in Maven Central.
Our version is actually the same as the one found on http://www.jcraft.com/jsch/
Also, the Maven JAR is properly signed with the author’s CA7FA1F0 key.
This is where it becomes clear that reproducible builds are important. You do not want to have to wonder why a binary differs, especially years later when you are doing a review. And this one is a library doing SSH!
So, why the different binaries?
It seems the original JAR was compiled on Aug 30, 2016 with Java 1.4 (major version 48) while the Maven Central JAR was compiled Sep 3, 2016 with Java 5 (major version 49).
The original JAR also concatenates strings using StringBuffer while the Maven Central JAR uses the newly introduced in 1.5 StringBuilder.
Which should also be a bit faster since it’s not synchronized.
Next, most of the cypher classes use some reflection via a static java.lang.Class class$(java.lang.String) method.
What is this? It’s just the way class literals worked in Java 1.4. //As explained here,
In Java 5 the ldc_w instruction was introduced to load a Class object.
In 1.4 the class literal was helped by the compiler by actually introducing the helper Class class$(java.lang.String className) method
and replacing the Person.class with a class$("Person") call.
It conclusion, it seems that excluding the Java 1.4 to Java 5 compiler changes, the two JARs are identical.
With the Maven Central JAR even a bit better due to StringBuilder being used.
There is no check so far that the sources do produce the specific JAR. This is an exercise left for the reader.
Watch this quick interview to learn about the status of the process at Apache NetBeans (incubating):
Clicking on the image above will load the video and send data from and to Google
Here, at last, is a community space for everyone working on Apache NetBeans, currently incubating, to post blogs.
I imagine this will be a place where we can announce new releases of Apache NetBeans, while it will also be a place for everyone to share their experiences and make all kinds of other announcements.
Happy blogging everyone, at the brand new Apache NetBeans (incubating) blog.
