Apache NetBeansCan I create a console or server (non-GUI) app with the NetBeans Platform?
While most documentation explains the NetBeans Platform in terms of Java desktop applications, it is possible to build a non-GUI application on the NetBeans Platform. This might be useful, for example, when creating a platform-based application which will distribute computationally expensive work among a group of machines. Note that this explains how to develop an application which is only ever meant to run headless, not how to develop a single application which can run in either GUI or command line mode (which is described in the second half of this page).
This is done by simply starting with the NetBeans Platform and removing all but the most essential components. NetBeans architect Jaroslav Tulach calls this subset of the NetBeans platform the "runtime container" and wrote an application which uses it to control his television.
Here are the steps for creating a runtime container application:
-
Create a new suite
-
Exclude all clusters from the suite
-
Re-enable the platform cluster, but disable all but the following modules:
-
Bootstrap
-
File System API
-
Lookup API
-
Module System API
-
Startup
-
Utilities API
-
-
Add a new module to the suite
-
Create and register a
ModuleInstallclass
-
The
restored()method is effectively your application’smainmethod.
-
You may optionally override the
close()method of yourModuleInstallto clean up resources upon shutdown, but be sure then to callLifecycleManager.getDefault().shutDown().
You will also need to suppress the splash screen by passing --nosplash argument when starting the app.
How Can I Make My NetBeans Platform Run in GUI or Command-Line Mode?
If your application performs some repetitive task like engineering analysis and you have some users who prefer using the command line and some who don’t, you may be asked to modify your application so that it can run in either the normal GUI mode or in batch processing mode from the command line.
The exact method for doing this will vary per application, but you will typically need to add a module to interpret some custom command-line arguments using the Command Line Processing API. Inside the process(Env env, Map<Option, String[]> map) method of your option processor, you’ll invoke whatever code corresponds to the arguments the user specified (e.g. myapp --import path/to/file.txt might import some file).
Remember that you should not use System.out, System.err and System.in for the output, error and input streams in the options processor but instead get them from the Env object passed as a parameter to the process method.
When running a platform application which contains the Window System and other GUI modules, you will also need to specify --nosplash --nogui on the command line at startup to prevent the splash screen and window system from being displayed. You may also wish to set the netbeans.logger.console system property to true (e.g. specify -J-Dnetbeans.logger.console=true on the command line) so that you will see NetBeans' error messages on the console. It might also be a good idea to specify the plugin.manager.check.interval=NEVER system property to avoid checks for new plugins when running in command line mode.
Finally, note that prior to NetBeans 6.10, the current working directory available from the Env object was set to the directory of the application’s installation, not the directory from which the command was executed. The consequence of this is that resolving relative file paths did not work as expected on Microsoft Windows systems, although it does work correctly on all versions of UNIX I tested. This has been resolved (https://bz.apache.org/netbeans/show_bug.cgi?id=189791), but the suggested workaround for affected versions of the platform is to introduce an additional batch file which invokes the NetBeans executable by passing in a Java system property that specifies the current (execution) directory.
Applies to: NetBeans 6.5 and later
