1. Writing Portable Code
NeuroKernel API tries not to use an extensive set of Java packages for portability. For an API, less libraries and methods you use for the target platform, more portable your code will be. Developers are free to write complex applications with deep dependencies. NeuroKernel API is also Java 6 compatible which means legacy platforms can also be supported. If a developer wants their NeuroKernel code to be portable, use only NeuroKernel supplied API and check if a package or method for the transpiler used is available on other supported platforms as well.
2. Compiling to ByteCode
Compiling a NeuroKernel application to Java byte code is the simplest approach in terms of compiling the code. Adding NeuroKernel API jar file to the classpath is all is needed.
2.1 Servlet Container
Developers can use any servlet container that implements Servlet 3+ specification. If servlet container does not support JSR 356, for web socket, use of Atmosphere project library is recommended. If you have a legacy server with a older Servlet specification, please contact us. We can provide you with a legacy build; however, additional license fees may apply. It may be required to put the servlet API and other related libraries on the classpath when compiling.
2.2 Command Shell
In Dynamic Edition, it is possible to open a VT terminal to your server where servlet container runs, and compile and run applications from the command line. It is even possible to plug command line applications into other applications. The display port is automatically set by the VT terminal and read by the compiled application. There is another library API file to use while compiling command line NeuroKernel applications. Terminal IO only works with NeuroKernel terminal, and it wont work with command line applications. If there is demand, we may offer an emulation for command line console input output which would function exactly same as NeuroKernel terminal. Command line applications are an important tool for developers to rapidly test or debug their code.
4. Compiling to WebAssembly
NeuroKernel WebAssembly support is still in the works, but we are pretty close. NeuroKernel has a high performance protocol, and that is going to be a winner for WebAssembly applications that does not want to use only Canvas to render. Please see our Experiments page for the details of the current WebAssembly support.
5. Using Generators
NApplication class when extended. Some transpilers supply tools to make generating these files easier, for others API has annotation processors available to be used under
NeuroKernel API has annotations that control the code generation while compiling the application. These annotations are used either by a compiler based API or an annotation processor that is available from the NeuroKernel SDK.
5.1.1 Configure Annotation
Configure annotation is the main configuration annotation for NeuroKernel application. It can also be used to optimize the size of compiled code.
5.1.2 Executable Annotation
Executable annotation is used to generate application launch code. An application bootstrap code can be written by the developer to support a specific launching process which may be passed as an argument to the generators.
5.1.3 Remote Annotation
Remote annotation is used to generate code for applications targeted for remote access. It can be used also to configure
Executable annotation. The “rexec” is the command that can be used to execute a remote application via the
5.1.4 ApplicationCache Annotation
NeuroKernel client side applications can be cached to the browser for offline access. This may be useful if the site to the application is down. the Service workers are used for this including a fallback to AppCache mode. There may be client based limitations that could be solved in a later version. Please take note that, the deployment must have HTTPS certification for this to work.
6. Supported Transpilers