When starting the standalone version via graphdb.cmd the following message is given:
"This GraphDB distribution requires Java 8, 11 or 12 but you have Java 15".
However, the startup is successsful and GraphDB WorkBench can be started.
Do I have to expect some "hidden" problems in the future use, when I keep running the system based on (Open)Java 15?
Theoretically speaking you should have no problems using Java 15, but this mean that GraphDB was not tested with this version and it's hard to say if there could be potential problems.
Related
I know Mule ESB Enterprise edition can be installed on Raspberry Pi because it ships with support for arm based processors. Unfortunately, Community edition does not have it. This makes it difficult to use Mule ESB on pi for longer time as I don't have the enterprise license (it's for personal projects and enterprise trial ends in 30 days). I wonder, why community edition does not have this support? Are there any restrictions for using community edition on pi?? Can the support be added to community edition? Has anyone done it and using it?
Yes, it is possible to install and run Mule on Raspberry PI 3 (and by extension any armhf/armel machine). You have to tweak your installation to ensure Mule uses the Linux armhf 32-bit Java Service Wrapper (or the related OS/architecture Wrapper). The steps in details:
Install Mule CE
Install Mule Standalone as you would do on any other machine:
Download the Mule CE Runtime
Unpack the content somewhere, such as in /opt/mule (i.e. MULE_HOME=/opt/mule) and change owner of the content to a Mule user (such as mule:mule)
Optionally, perform some hardening
You should be able to run Mule using $MULE_HOME/bin/mule start|stop|restart
Configure Java Service Wrapper
You need to manually add the Java Service Wrapper support for your OS and processor architecture, for Raspberry PI 3 it would be Linux armhf 32-bit.
Download the Linux armhf 32-bit Community Tanuki Java Service Wrapper and unpack it
Copy the Wrapper lib/libwrapper.so to $MULE_HOME/lib/boot/libwrapper-linux-armhf-32.so, ensure it has read+execute permission and is Mule user owned
Copy the Wrapper lib/wrapper.jar to $MULE_HOME/lib/boot/wrapper-{version}.jar (replace {version} by your Wrapper version), ensure it's Mule user owned and remove or backup somewhere else the previous wrapper-{oldVersion}.jar
Copy the Wrapper bin/wrapper to $MULE_HOME/lib/boot/exec/wrapper-linux-armhf-32, ensure it has read+execute permission and is Mule user owned
This one is a bit tricky, you have to update the $MULE_HOME/bin/mule launch script. Look for the line case "$PROC_ARCH" in, Such as:
'x86_64')
DIST_ARCH="x86"
DIST_BITS="64"
break;;
Each case match a specific hardware name to define DIST_ARCH and DIST_BITS variables, allowing to use the proper Wrapper files. Add a new case to handle your Raspberry PI hardware. For Raspberry 3, it's should be something like armv71 (check with uname -m if required):
'armv71')
DIST_ARCH="armhf"
DIST_BITS="32"
break;;
You may need to update $MULE_HOME/conf/wrapper.conf to avoid memory related issues. I usually have to play around with the following properties:
wrapper.java.initmemory=512
wrapper.java.maxmemory=512
wrapper.java.additional.X=-XX:PermSize=256m
wrapper.java.additional.Y=-XX:MaxPermSize=256m
wrapper.java.additional.Z=-XX:NewSize=512m
wrapper.java.additional.V=-XX:MaxNewSize=512m
When Mule will run on armv71 hardware, it will now use wrapper-{OS}-{DIST_ARCH}-{DIST_BITS}, in our case wrapper-linux-armhf-32. You should be able to run Mule as usual - check the logs for any error on start-up.
This method has been tested with Raspberry PI 2 and 3 for Mule CE 3.7 and 3.8 (it should work for previous versions). It may be a bit tricky, if you have any issue post a comment I'll update this post to add details.
By the way, this method can be used to add support for any architecture and OS as long as it is supported by Java Service Wrapper.
I wonder, why community edition does not have this support?
I don't know, Mule CE simply does not support ARM architecture - for now. Only a limited list of platform and architecture is supported by CE (i.e. the launch script filtering architecture types). Maybe they simply did not take the time (~money) to add support, or they purposefully prevent ARM support to favor Mule EE. Considering Mule CE is open-source, in theory someone could contribute to add such support... (just saying ! :)
I read a few posts about JVM at Stack Overflow and would like to download a binary copy of the Hotspot JVM, yet I am not able to find it on http://www.java.net.
Beside that, what is the difference between Hotspot JVM and JVMs found at Oracle
Is Oracle JVM good for a production website?
Overview:
This SO question may clear up your questions regarding "What is JVM, Hotspot and OpenJDK".
Basically:
JVM means Java Virtual Machine. The JVM is the underlying runtime that executes java bytecode. There are multiple different implementations out there, all implementing the Java Virtual Machine Specification
HotSpot is the most used implementation of the JVM concept. It is used in both, Oracle JDK and OpenJDK. Oracle's JDK can be downloaded on oracle's website, currently http://www.oracle.com/technetwork/java/javase/downloads/index.html. This is "the typical JVM you will find on a normal user's windows machine".
OpenJDK is the open source project maintaining and impelmenting the HotSpot JVM, but also many other projects beside the JVM such as Graal or VisualVM. On Ubuntu for example you can install this OpenJDK (current version 8) by running sudo apt-get install openjdk8.
Conclusion:
While this explaination is not really perfect, it may be good enough to understand that there is no big difference between Oracle JDK and OpenJDK. If you are interested in a little more info on this, have a look at the SO question Differences between Oracle JDK and Open JDK
JDK / JVM sourcecode:
If you are interested in the source code, OpenJDK is the way to go. Here you can find the current OpenJDK 8 (which includes the HotSpot JVM). Its source code can be found here. It also states how to download the source code:
The jdk8u-dev forest for ongoing development can be cloned using this command: hg clone http://hg.openjdk.java.net/jdk8u/jdk8u-dev;cd jdk8u-dev;sh get_source.sh .
The corresponding master forest jdk8u can be cloned using this command: hg clone http://hg.openjdk.java.net/jdk8u/jdk8u;cd jdk8u;sh get_source.sh .
In addition, the source code for the last release, 8u66, is available by cloning the 8u master forest : http://hg.openjdk.java.net/jdk8u/jdk8u and using the 'jdk8u66-b17' mercurial tag.
I am getting following error while running /tmp/jprofiler8/bin/jpenable
No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.6 and at most 1.7.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
You can also try to delete the JVM cache file
I have also set INSTALL4J_JAVA_HOME to point to suitable JVM.
Java version on my machine is 1.4.2.
Can anyone please suggest what might be wrong or missing?
Unfortunately you did not mention details about your environment, so I don't know which Linux distribution you use.
There are some options though:
install a current JRE alongside the installer for JProfiler
As you can't install or update Java, you could provide a JRE in a kind of "portable application" setup. Simply unzip the server jre Oracle provides or (if you are not on an x64 architecture) unzip the jdk you also can download from Oracle.
But if the code you want to profile is limited to your pre-installed Java 1.4 you will run into another problem, because as far as I know Java 1.5 is the minimum JProfiler expects
use a different machine for profiling
Unless your code depends heavily on the environment you run it in you can even take a Windows 8.1 machine and profile the code there. Code that is slow is slow on any operating system. Or make use of a different Linux computer.
Would I encounter any problems running Java programs and associated libraries compiled in Java version 1.6 and 1.7 (I'm compiling using 1.7 whereas some libraries are compiled using 1.6) and running the entire program in a 1.7 JRE?
As answered already you are mostly safe and most products and 3rd party libraries will simply work. However there do exist very rare cases where binary incompatibilities (ones where the class file compiled using older JDK will fail to run in the newer JVM) were introduced between JDK versions.
Official list of Oracle Java incompatibilities between versions:
in Java SE 9 since Java SE 8
in Java SE 8 since Java SE 7
in Java SE 7 since Java SE 6
in Java SE 6 since Java SE 5.0
in Java SE 5.0 since Java SE 1.4.2
Compatibility tool
Packaged with JDK 9, there is a tool called jdeprscan which will verify the compatibility, list no longer used APIs within your code and suggest alternatives(!). You can specify the target JDK version (works for JDK 9, 8, 7 and 6) and it will list incompatibilities specific to your target version.
Additional comment in case of libraries:
A reasonable rule of thumb is to use latest stable release version of library for the JRE version your software targets. Obviously you will find many exceptions from this rule, but in general stability of publicly available libraries usually increases with time.
Naturally API compatibility and versioning have to be considered when changing versions of dependencies.
Again most popular dependencies will have web pages where such information should be available.
If however you are using something a bit more obscure, you can discern which JRE were the classes within your dependency compiled for.
Here is a great answer on how to find out class version. You might need to unzip the JAR file first.
You would not encounter any problems - that's the magic of Java -it's backwards compatible.You can run almost all code from Java 1 on Java 8. There's no reason why Java 6 code won't run on a Java 8 Runtime.
What is interesting, is that for applications written in, let's say, Java 1.4, you even have speed increases when running them on later runtimes. This is because Java is constantly evolving, not just the language known as "Java", but also the JVM (Java virtual machine). I still have source code from more than 10 years ago that still work, as expected in the latest JVM.
If you want to target, let's say, a Java 5 VM, then you can do that with the Java 8 SDK tools. You can ultimately specify which target VM you wish to support, as long as you bear in mind that a version 5 VM might not support all the features a version 8 VM will.
I've just tested code I wrote in Java 5 against the new Java 8 runtime and everything works as expected, so, even though we have a more powerful language and runtime now, we can continue to use our investments of the past. Just that alone makes Java a great development choice for companies.
I have been using the dynamic code evaluation for dynamic loading of my changed classes in my Jboss server ,
I have found this tool very helpful and interesting , but it have a problem that it works with jdk 1.6 , but As i am trying to use java 7 in my project it fails .
Can anyone suggest similar type of tool with java7 support
I suggest using... the Dynamic Code Evolution VM for Java 7 :) The DCEVM web site is not up to date and the version available for download there doesn't work with the latest versions of Java 7. For some time the Mercurial repository contained a more recent version and it has been eventually forked on Github where binaries for Windows and Linux are provided. On Debian/Ubuntu DCEVM is also available after installing the openjdk-7-jre-dcevm package.