One characteristic of Java is portability, which means that computer programs written in the Java language must run similarly on any hardware/operating-system platform. This is achieved by compiling the Java language code to an intermediate representation called Java bytecode, instead of directly to platform-specific machine code. Java bytecode instructions are analogous to machine code, but are intended to be interpreted by a virtual machine (VM) written specifically for the host hardware. End-users commonly use a Java Runtime Environment (JRE) installed on their own machine for standalone Java applications, or in a Web browser for Java applets.
Standardized libraries provide a generic way to access host-specific features such as graphics, threading, and networking.
A major benefit of using bytecode is porting. However, the overhead of interpretation means that interpreted programs almost always run more slowly than programs compiled to native executables would. Just-in-Time compilers were introduced from an early stage that compile bytecodes to machine code during runtime.
Just as application servers such as GlassFish provide lifecycle services to web applications, the NetBeans runtime container provides them to Swing applications. Application servers understand how to compose web modules, EJB modules, and so on, into a single web application, just as the NetBeans runtime container understands how to compose NetBeans modules into a single Swing application.
Modularity offers a solution to “JAR hell” by letting developers organize their code into strictly separated and versioned modules. Only those that have explicitly declared dependencies on each other are able to use code from each other’s exposed packages. This strict organization is of particular relevance to large applications developed by engineers in distributed environments, during the development as well as the maintenance of their shared codebase.
End users of the application benefit too because they are able to install modules into their running applications, since modularity makes them pluggable. In short, the NetBeans runtime container is an execution environment that understands what a module is, handles its lifecycle, and enables it to interact with other modules in the same application.
Registration of various objects, files and hints into layer is pretty central to the way NetBeans based applications handle communication between modules. This page summarizes the list of such extension points defined by modules with API.
Context menu actions are read from the layer folder Loaders/text/x-ant+xml/Actions.
Keymaps folder contains subfolders for individual keymaps (Emacs, JBuilder, NetBeans). The name of keymap can be localized. Use “SystemFileSystem.localizingBundle” attribute of your folder for this purpose. Individual keymap folder contains shadows to actions. Shortcut is mapped to the name of file. Emacs shortcut format is used, multikeys are separated by space chars (“C-X P” means Ctrl+X followed by P). “currentKeymap” property of “Keymaps” folder contains original (not localized) name of current keymap.
This folder contains registration of shortcuts. Its supported for backward compatibility purpose only. All new shortcuts should be registerred in “Keymaps/NetBeans” folder. Shortcuts installed ins Shortcuts folder will be added to all keymaps, if there is no conflict. It means that if the same shortcut is mapped to different actions in Shortcut folder and current keymap folder (like Keymap/NetBeans), the Shortcuts folder mapping will be ignored.
* DatabaseExplorerLayerAPI in Database Explorer
* Loaders-text-dbschema-Actions in Database Explorer
* Loaders-text-sql-Actions in Database Explorer
* PluginRegistration in Java EE Server Registry
XML layer contract for registration of server plugins and instances that implement optional capabilities of server plugins. Plugins with server-specific deployment decriptor files should declare the full list in XML layer as specified in the document plugin-layer-file.html from the above link.
“Projects/org-netbeans-modules-java-j2seproject/Customizer” folder’s content is used to construct the project’s customizer. It’s content is expected to be ProjectCustomizer.CompositeCategoryProvider instances. The lookup passed to the panels contains an instance of Project and org.netbeans.modules.java.j2seproject.ui.customizer.J2SEProjectProperties Please note that the latter is not part of any public APIs and you need implementation dependency to make use of it.
“Projects/org-netbeans-modules-java-j2seproject/Nodes” folder’s content is used to construct the project’s child nodes. It’s content is expected to be NodeFactory instances.
“Projects/org-netbeans-modules-java-j2seproject/Lookup” folder’s content is used to construct the project’s additional lookup. It’s content is expected to be LookupProvider instances. J2SE project provides LookupMergers for Sources, PrivilegedTemplates and RecommendedTemplates. Implementations added by 3rd parties will be merged into a single instance in the project’s lookup.
Use OptionsDialog folder for registration of custom top level options panels. Register your implementation of OptionsCategory there (*.instance file). Standard file systems sorting mechanism is used.
Use OptionsDialog/Advanced folder for registration of custom panels to Miscellaneous Panel. Register your implementation of AdvancedCategory there (*.instance file). Standard file systems sorting mechanism is used.
Use OptionsExport/<MyCategory> folder for registration of items for export/import of options. Registration in layers looks as follows
Source files must be named after the public class they contain, appending the suffix .java, for example, HelloWorldApp.java. It must first be compiled into bytecode, using a Java compiler, producing a file named HelloWorldApp.class. Only then can it be executed, or ‘launched’. The Java source file may only contain one public class but can contain multiple classes with less than public access and any number of public inner classes.
A class that is not declared public may be stored in any .java file. The compiler will generate a class file for each class defined in the source file. The name of the class file is the name of the class, with .class appended. For class file generation, anonymous classes are treated as if their name were the concatenation of the name of their enclosing class, a $, and an integer.
The keyword public denotes that a method can be called from code in other classes, or that a class may be used by classes outside the class hierarchy. The class hierarchy is related to the name of the directory in which the .java file is located.
The keyword static in front of a method indicates a static method, which is associated only with the class and not with any specific instance of that class. Only static methods can be invoked without a reference to an object. Static methods cannot access any class members that are not also static.
The keyword void indicates that the main method does not return any value to the caller. If a Java program is to exit with an error code, it must call System.exit() explicitly.
The method name “main” is not a keyword in the Java language. It is simply the name of the method the Java launcher calls to pass control to the program. Java classes that run in managed environments such as applets and Enterprise JavaBean do not use or need a main() method. A Java program may contain multiple classes that have main methods, which means that the VM needs to be explicitly told which class to launch from.
The main method must accept an array of String objects. By convention, it is referenced as args although any other legal identifier name can be used. Since Java 5, the main method can also use variable arguments, in the form of public static void main(String… args), allowing the main method to be invoked with an arbitrary number of String arguments. The effect of this alternate declaration is semantically identical (the args parameter is still an array of String objects), but allows an alternative syntax for creating and passing the array.
The Java launcher launches Java by loading a given class (specified on the command line or as an attribute in a JAR) and starting its public static void main(String) method. Stand-alone programs must declare this method explicitly. The String args parameter is an array of String objects containing any arguments passed to the class. The parameters to main are often passed by means of a command line.
Printing is part of a Java standard library: The System class defines a public static field called out. The out object is an instance of the PrintStream class and provides many methods for printing data to standard out, including println(String) which also appends a new line to the passed string.