Bundle GraalVM engine and graalpython with Java application - java

There is a way to run Python scripts that uses packages from Java using GraalVM and its Python module graalpython. Here is example https://github.com/paulvi/graalpython-java-template
I wonder if it is possible to bundle GraalVM engine and graalpython into my Java application and produce jar or native image (e.g. using native image compiler from GraalVM project ) ?

I think you can bundle whole GraalVM distribution with your application, like some other applications do with normal JDKs (e.g., I think IntelliJ bundles JDK with it). That would be the simplest option.
You need at least the GraalPython home directory, which contains Python standard library and other files necessary for GraalPython to run any meaningful program.
Moreover, if you want to run in JVM mode, then you need to run on GraalVM, other JDKs are not supported. In theory you could perhaps hack it somehow to run GraalPython on stock JDK with JVMCI, like it is possible with JavaScript [0], but it is going to be much more complicated with GraalPython.
In theory, you can bundle GraalPython home directory into your application by providing custom filesystem implementation [1].
[0] https://www.graalvm.org/reference-manual/js/RunOnJDK/
[1] https://www.graalvm.org/truffle/javadoc/org/graalvm/polyglot/io/FileSystem.html

Related

Diffrence between Java Custom JRE and Java Native Image

In addition to developing classic services on Spring Boot, I want to know Java with it environment better.
When I began to study portability, I came across such concepts as custom JRE (jlink, jmods) and native image (GraalVM, Liberica NIC).
As I understand :
Custom JRE for creating distribution folder with executable file. In folder only necessary dependencies. It arrived in Java 9
Native image for creating executable all in one JAR
Which of them should be used in which cases?
First of all, you should know what a JRE (Java runtime environment) is. Basically, it includes everything required to run Java applications that are already built. A JDK (Java Development Kit) is a superset of a JRE, adding the tools for developing Java applications.
With jlink, you can create JRE images. This means you are creating a Java installation that is capable of running your Java program. This can be done in a way so it only contains the necessary modules. jpackage allows you to create an installer for such a JRE.
On the other hand, a native image is a version of your code that's compiled and optimized for a specific target platform. Typically, it's a single executable file that runs your code. When creating a native image, it takes your application and converts (compiles) it to a platform specific executable (unlike jlink which creates a JRE that is able run your "normal" JAR).
Native-image does not generate a JAR but an ELF/EXE file which can be executed on your device without a Java installation while jlink just creates a (minimal) Java installation capable of running your application.
It should be noted that native-image comes with a few limitations. For example, remote class loading is not possible and if you use Reflection, you need to specify what to reflectively access at compile-time.

Testing for Java SDK

I am writing an application in Java. Does a Java SDK have to be installed to run the application from the command line? If so, can I package the SDK with the application to be installed when installing the application?
From Java 9 onwards you can use jlink to produce a custom JRE for your application. The JRE includes a copy of the java command and (only) the libraries / classes that your application needs. It will be platform specific.
From Java 14 onwards, you can use jpackage to produce (platform specific) native executables for Java applications.
There are also 3rd-party tools that can generate executables, and third party installer generators that (in some cases) can install Java for the end user.
Note: if you take the approach of distributing your application as a self-contained JRE or native executable, the user no longer has the option of updating their Java to address security related issues. It becomes your problem / responsibility ... as the supplier of the software ... to make available in a timely fashion application updates that incorporate the new Java releases with important security patches.
If you use something like GraalVM to compile a native binary, then there is nothing more you should need for a simple application (meaning, nothing is tried to dynamically load classes at runtime with reflection)
Other than that, the Java JRE is required, and can be included as part of an application package; for example, IntelliJ or Eclipse IDE come with their own JRE.
Thanks everyone for your input.
After doing more research I found that by using a jdk greater than 8.?, it is possible to bundle everything an application needs in the deployment process.

A *.exe app made in java, to execute it needs to have java installed?

A *.exe app made in java, to execute it needs to have java installed?
I transformed a *.jar into an *.exe and I don't know if it can run well in *.exe mode.
Generally yes you will need to have java installed.
It depends on the packager, Java knows nothing about .exes, so you used some external tool to package your exe as a jar. That tool COULD put the entire JVM into the .exe, but it's very unlikely.
Some also recompile it to native code (Jikes if it's still around is one) but that might still need access to jave install so it can get at the libraries... but it may also be able to re-compile the required libraries and include them in the exe
In other words, it all depends on the packager, look at it's documentation.
You will need something like exec4j:
https://www.ej-technologies.com/download/exe4j/files
From their website:
exe4j is a Windows launcher generator.
exe4j is useful if you want to create a Java launcher without an installer.
This will package your java project/JAR into a Windows .EXE file, and optionally bundle a JRE into the package so that your users are not required to have a local JRE already installed.
A JRE needs to be available at runtime for your application to work, so you can either bundle it into your executable, or have the user install one onto their system.
If your project is OpenSource, and has a website, generally EJ Technologies (the company behind exec4j, install4j, jProfiler, and other great Java technologies) will provide you with a free OpenSource License.

How to do a professional setup for java app to avoid "javaw" cannot be found?

I just installed http://yacy.net/
It advertises as easy install except that when I run it says cannot find javaw which spoils nearly everything.
If I were to distribute a java app myself I'd like not to have user knows anything about downloading and installing java, so any article, tool which explains how to package a java app professionally like one can do with a windows app easily ?
There are several approaches to this, all of which have their own set of drawbacks. Here are some of the most popular:
Bundle a private JRE with your application. See the README file that comes with your JRE for the details.
Use a launcher (such as launch4j) that can download a JRE at runtime if a suitable one is not found on the target machine.
Compile Java to native, then distribute as a regular Win32/Linux executable. You can do this with Excelsior JET.
Since you are concerned with deployment, you'll probably also want to create an installer for your application. There are dozens of options for this, such as NSIS.

What is the best way of packaging Java software for running on Windows?

What's the best way to package Java software for running on Windows? Is there a standard for writing .BAT files which can discover the latest installed JRE on the machine? Are there any Maven plugins for this? What's the deal with executable Jar files?
I would without any doubt recommand you to use Java Web Start, as it allows you easy control over version used (and by far the easier to use update mechanism available nowadays).
Depends on what you need.
We've found that using the One-JAR + JSmooth gives a very good user experience as it allows us to distribute a single EXE-file which can be put anywhere on the users system, as opposed to having installation binaries, which need to be installed and uninstalled etc. etc. etc. JSMooth checks for the existance of the appropriate Java runtime, and redirects to the official download site if none is found.
The reason for One-jar is that you generally need to use library jars which is best to have separately but JSmooth only allows for a single jar file.
Also the One-Jar SDK and JSmooth is scriptable without being tied to Windows, so we can build new versions on our Hudson engine running on Linux.
In the past I've used a java installer package like launchForJ. However, a lot of these packages use Java so you may need to a batch or simple executable written in native windows code that does a quick check to see if Java is already installed then run the installer.
Since Java uses system variables during install you should be able to check if the version (or higher) that you require exists in this way.
The standard way would be to use Java Web Start.
Using Java Web Start technology, standalone Java software applications can be deployed with a single click over the network. Java Web Start ensures the most current version of the application will be deployed, as well as the correct version of the Java Runtime Environment (JRE)
Maven has a Webstart Maven Plugin to help building application bundles that can be deployed via Web Start.
An alternative solution would be to use a cross-platform installer generator to generate, well, an installer. I personally like IzPack (I think that JSmooth is very similar but I have more experience with IzPack) and, if you are specifically targeting the Windows platform, you could use IzPack to Build [a] Native Windows Installers with IzPack Native Launcher:
A problem still arise with IzPack when
the target system does not have a JRE
installed. The user needs to first
install it and then run the IzPack
installer. This is not a problem with
Linux or BSD users since they are
generally skilled and they know how to
do that by hand or with a packaging
system (RPM, DEB, ebuilds, ports,
...). Similarly, a Mac OS X user will
not have much problems since it is
available with the operating system.
However the situation is more
complicated on the Windows platform as
a JRE must be installed. Worse,
several instances can be installed in
a sometimes messy situation.
The IzPack Native Launcher tries to
solve this problem. It is a C++ native
application that is available under
the very permissive MIT License and
that uses wxWidgets for the GUI. It is
thus cross-platform (for the
historians: it was first developed on
a FreeBSD box), but most people will
need it on Windows. It uses a simple
configuration file and will first
check for a JRE. If none can be found,
it will pop-up a dialog to let the
user choose between the following
options:
manually specify a JRE location
download one from the Internet
install one that is provided by the packager (if available).
IzPack also offers a Maven Plugin. Worth the check.

Categories