INT

Empowering Visualization

CONTACT US SUPPORT

NetBeans

What We Learned about the Future of NetBeans from the Last 2 Years

It’s been two years since Oracle announced the donation of the NetBeans source code to the Apache software foundation. This move was much more than a licensing change — it was a bit of a new beginning for NetBeans.

The NetBeans IDE is well liked at INT. In fact, INTViewer is built on top of the NetBeans platform, and the IVAAP backend was entirely written with the NetBeans IDE. With the release of NetBeans 10, now is a good time to look back and recognize the changes that this transition to Apache brought.

Better Licensing
Under Oracle’s stewardship, the NetBeans source code was available under two licenses: a Common Development and Distribution License (CDDL) and a GNU General Public License (GPL). The CDDL is not well known, and the GPL sometimes carries stigma. The license move is a clear win for the platform as Apache is appreciated in the Java community for its business-friendly license and ubiquitous libraries.

Open Governance
The Apache NetBeans project is still “incubating.” The incubation process allows the foundation to assess whether the donated code complies with legal standards and how the community adheres to Apache’s guiding principles. These principles are centered around openness and collaboration. You can see it at work on NetBeans’ own website: all communications are recorded and shared. This is actually a requirement from the Apache foundation to use mailing lists. No conversations behind closed doors. No secret agenda. When decisions are made, you can see how the consensus was built. The NetBeans project didn’t just get a “new home,” it inherited a renewed philosophy, a new process, moving from “open source” to “open governance.”

Ongoing Support
Oracle has been a significant contributor to NetBeans in the past. Despite the spin off, Oracle’s contributions continue to this day — the NetBeans project received in June a second code donation from Oracle, a donation that will enable JakartaEE projects. Two years ago, observers were worried that Oracle might be “abandoning” NetBeans to Apache. However, the last two years have proved that Oracle still intends to spend resources on NetBeans.

The move to Apache was also a good opportunity to modernize the community tools: Bugzilla was retired, making room for JIRA, and self-hosted Mercurial was replaced by Git, hosted on GitHub. These changes make contributions from developers easier to make, giving the community much more freedom to control its future.

The timing of this transition wasn’t the best. Effort that would have normally been spent by the NetBeans community to support Java 9, 10, and 11 was spent instead meeting Apache’s legal requirements. The release of NetBeans 10 officially closes this chapter. The NetBeans developers need to be recognized for their efforts during these two years. As all Java developers can attest, the transition to Java 11 of any code base is a challenge. This was certainly even more true for a large code base such as NetBeans’.

What’s Next for NetBeans?
This chapter has yet to be written. Discussions point to frequent updates, maybe every 6 months. Meanwhile, INT is working actively to integrate the NetBeans 10 platform to INTViewer. Personally, I feel that the NetBeans project is likely to attract a new crowd of developers. Developers who have an itch to scratch. Since the users of the NetBeans IDE are developers themselves, there is a definite sense that filing bug reports or proposing new features won’t be enough to get things done. Pull requests make it easier than ever to submit changes and I plan to scratch long-time itches myself — maybe INTViewer would benefit from some tweaks to the NetBeans window system. It’s time for all of us to use these newfound abilities.

Visit our products page for more information about INTViewer or IVAAP or contact us for a demo.


How the NetBeans Module System Helps Us Maintain Compatibility Between Releases

Most of the talk about Java 9 has been about the new module system. Two decades after its creation, the Java runtime has finally become modular. A modular approach not only makes dependency management easier, but it also makes applications more efficient as unused modules don’t need to be loaded.

The NetBeans Platform predates Java 9 and has been using its own module system for years. With INTViewer being a desktop application built on top of the NetBeans Platform, I have come to like this system and I’d like to talk about 3 aspects in which it is far superior to the Java 9 module system for my use cases.

Split Packages

One of the core aspects of both the NetBeans Platform and the Java 9 module system is that modules are identified uniquely by a root package name. Where they differ is that the Java 9 module system doesn’t allow two modules to have classes under the same root package name. The logic behind this is that the Java runtime can’t quickly resolve where to find each class if the rules to find the matching module are complex or even ambiguous. Java 9 doesn’t allow so-called “split packages.”

The NetBeans Platform doesn’t have this restriction, and over the 10 years that I have worked on INTViewer, this has helped us tremendously building INTViewer as a modular platform. Many times, we found ourselves realizing that one module was “too big” and needed to be split. If we had to follow the “no split packages” rule, we would have had to change the package of some classes, breaking class-level backward compatibility.

This “stable class-level API” is a very important concern for us. With customers and vendors building their own applications on top of INTViewer, we can’t afford to change the public API at each release. Our customers wouldn’t allow it: they can’t refactor their code so often. When we do need to split a module, customers are generally okay with changing the coarse-grained dependencies of their app; adding a new module to their dependencies is easy and doesn’t require any code change.

Module Versioning

It’s a simple feature, but very powerful. When INTViewer starts, the NetBeans Platform verifies every plugin before it gets loaded. If one of them relies on another module that is not present, this plugin doesn’t load. Similarly, if a plugin requires a module to be up-to-date and the NetBeans Platform finds that this requirement is not met, this plugin won’t load. Practically, this prevents mixing plugin versions. A plugin built for INTViewer 5.2 won’t load in INTViewer 5.1. The NetBeans Platform gives immediate feedback to the person performing the plugin installation.

The Java 9 module system doesn’t support module versioning. The versioning concern is left to the dependency-resolution systems like Maven. But these systems perform checks at compile time, not when the application is used.

Mixing Library Versions

This is not a trick we use often, but it’s a lifesaver when we have to. When our customers build their own plugins, they typically leverage .jar files built by other entities. We do, too, and in a typical Java application, there is only one class loader to load all these .jar files. If two versions of the same library are present, the resolution of class names is ambiguous and the application fails in strange ways. The Java 9 module system doesn’t provide a direct way to address this concern.

The NetBeans Platform uses its own class loaders. To simplify, each module has its own. Each class loader only needs to deal with a well-defined set of dependencies, and other class loaders are not affected by these dependencies.

For example, we have two optional plugins making use of the JAXB library, a popular building block to read XML files. One of them is the VTK plugin, a plugin to visualize 3D models. Another one is the Reservoir plugin, a plugin to visualize RESQML datasets. These two plugins can coexist in the same INTViewer deployment without problems, and they don’t even need to have the same version of JAXB.

In a classic Java application, a choice would have to be made: which version of JAXB is “the right one,” and the module using the “wrong version” would have to be updated. The NetBeans Platform makes it really easy to deal with these version conflicts. As a result, INTViewer customers are not faced with refactoring their code for each release just because another unrelated module needed a more recent version of a specific library.

INT has greatly benefited from the NetBeans Platform. Its module system is both powerful and easy to use. It has allowed us to provide, release after release, a painless way to maintain INTViewer plugins, for ourselves and for our customers.

For more information about INTViewer, visit the INTViewer product page, or contact us for a free trial.


3 NetBeans Shortcuts to Help You Be More Productive

I have been using NetBeans daily for about 8 years, so I’d say I am pretty familiar … with the features I use all the time. Over the years, friends and colleagues have shown me that there are faster ways to get the job done. I have gathered in this post three shortcuts that I learned from others and that you can also use when you develop an INTViewer plugin.

#1 Finding a class file in the Project Tree

A software like INTViewer has thousands of source files, spread over dozens of plugins. As I am in the process of editing one file, I often find myself needing to find out which other files are related: I need contextual information about the file I am changing or I need to commit all changes to that module at once.

The project view before Shift+Ctrl+1 is pressed.

 

The shortcut to do this is to type Shift+Ctrl+1 on your keyboard.

The project view after Shift+Ctrl+1 is pressed.

 

This shortcut opens both the package where the file resides and the module that contains that file.

#2 Closing all other files

The process of writing software is not a continuous flow. I work on several aspects of the software at the time, with lots of interruptions. Sooner or later, I have several dozens of unrelated files open. When I need to work on a tricky part of the code, the first task is to clear the clutter.

The NetBeans makes it easy: the “close button” of each NetBeans window has a handy tooltip that informs you of available shortcuts.

The NetBeans tooltip for the window close button.

 

By pressing the Alt key as I am clicking this close button, I isolate the associated file, closing all other files that are open. I do this for each group of windows, and in 2 or 3 clicks, I reduced my clutter to the 2 or 3 files that matter.

Interestingly, because INTViewer is based on the NetBeans platform, INTViewer users also benefit from the same feature. If I have several INTViewer windows open, I can click on the one window I want to keep, automatically closing all others in the same tab group.

The INTViewer tooltip for the window close button.

 

#3 Loading already-configured projects

INTViewer itself is made of more than 80 plugins, but there are at least 50% more that are not part of the standard distribution. They are proprietary customer plugins, community plugins that we share with all our users, prototype plugins that we are working on. I sometimes need to run these plugins on top of the “bleeding edge” version of INTViewer’s code, sometimes on specific distributions that customers already use, sometimes on top of other plugins. The project configuration possibilities are endless, but I tend to use about 10 of these different configurations all the time.

NetBeans has a feature called Project Groups to facilitate switching between project configurations. To save your current project configuration, go to File→Project Groups. You will see a dialog with a button New Group that leads to the screen below:

This dialog proposes several options on how to create your project group. I typically use the Free Group option and press the Create Group button.

To load a project group already created, go to File→Project Groups, pick the project group that you need to work on, and choose Select Group

Your project tree will load exactly as you left it when you saved it as project group.