Can I create a console or server (non-GUI) app with the NetBeans Platform?
Can 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 (http://netbeans.org/bugzilla/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