On the shoulders of giants

Building an open source app atop the Apache NetBeans Platform

Being a single developer of a project like Mapton makes it essential to rely on others where doable. Mapton relies heavily on Apache NetBeans Platform and has been doing so since its [Mapton] beginning.

The primary benefits were the Window, Lookup and Plugin systems. Until recently, Mapton had its own custom versions of 

  • a menu
  • a toolbar
  • a statusbar
  • a notification system
  • an internal search system

Lately, work has been made in order to replace all of that with pure NetBeans ones. What a treat it was, so much time saved, now and in the future. Not to mention how great it feels to use the final product, based on a platform well crafted over close to 25 years.

So far, Mapton is using the following notable platform components:

  • Window system 
  • Menu & status bar
  • Printing system
  • Output log
  • Notifications
  • Plugins
  • Options
  • Lookup
The Window system in full action
The Options dialog
The Plugins dialog

The Apache NetBeans Platform is powerful, just pick and use what you need and like. 

It is well documented, there are many books on the subject as well as a NetBeans Platform Learning Trail.

All of this stable-free-and-ready-to-use-for-any-application makes the development of Mapton able to focus on what makes Mapton Mapton,
maps and spatial data, sometimes time coded.

Caps off to all individuals and organisations involved in NetBeans in one way or another over the years and a special thanks to the Apache Foundation for being a good host for the project since a couple of years.

Patrik Karlström, developer of Mapton

Distributing NetBeans Platform with JavaFX really do work

It was really easy in the past when one could just distribute the application and then relying on the “world wide” JRE to take care of the rest. That is not the case after Java 8.

For the last 7 months or so I have been working on moving Mapton from Java 8 to Java 11 and beyond.

I’ve tried many setups back and forth:

  • using the Platform JavaFX modules,
  • using jars,
  • using the AzulFX and LibericaFX JRE’s,
  • among other things. 

I ended up with the following workflow:

  1. Run NetBeans on a JDK with bundled JavaFX modules
  2. Just use JavaFX classes, without using any fx dependencies, exclude if necessary
  3. Use jlink to create a custom, one for each OS, JRE based off AdoptOpenJDK and the latest JavaFX jmods from Gluon

…and the thing is, creating a custom JRE was the general advice all along.

I guess it’s just to roll with the changes. 🙂