'. '

OpenJDK

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (12:59, 18 March 2014) (edit) (undo)
(Jan 30, 2014 update)
 
(13 intermediate revisions not shown.)
Line 1: Line 1:
-
A version of [[JDK]] released under [[GPL]] open source license: [[wikipedia::OpenJDK]].
+
[[wikipedia::OpenJDK|OpenJDK]] is a version of [[JDK]] released under [[GPL]] (with [[GNU Classpath]] exception) [[open source]] license. [[OpenJDK]] comes with various ''improvements'' over the classical [[Oracle]]'s [[JDK]] which often makes the [[OpenJDK]] much less usable than the original. One of the problems is the modified launcher parameters as described in [[Virtualization]] page. Instead of being helpful, it just makes the whole system unusable. However, at least the system starts.
-
It comes with various ''improvements'' over the classical [[Oracle]]'s [[JDK]] which often makes the [[OpenJDK]] much less usable than the original. One of the problems is the modified launcher parameters as described in [[Virtualization]] page. Instead of being helpful, it just makes the whole system unusable. However, at least the system starts.
+
For a while I've been struggling with [[Java]] on my hosted [[Linux]] (running [[CentOS]]). Whenever I tried:
-
 
+
-
For a while I've been struggling with java on my hosted [[Linux]] (Cent OS). Whenever I tried:
+
<source lang="bash">
<source lang="bash">
Line 12: Line 10:
</source>
</source>
-
Why? The system has a lot of resources, so where is the problem? It turned out that the workaround is easy. Just to limit the number of available memory:
+
Why? The system has a lot of resources, so where is the problem? It turned out that the workaround is easy. Just to limit the number of available memory (this by itself is ridiculous, but it shows that allowing [[virtualization]] is not the primary driver for evolution of [[Java]] technology):
<source lang="bash">
<source lang="bash">
Line 22: Line 20:
</source>
</source>
-
The question however is: How to modify each [[JDK]] utility ('''jar''', '''javac''', '''javadoc''', etc.) to use this changed setting? For a while I thought it is impossible, but today I realized that
+
==== Global Configuration ====
 +
 
 +
The question however is: How to modify each [[JDK]] utility ('''jar''', '''javac''', '''javadoc''', etc.) to use this changed setting? Usual [[Unix]] style is to locate ''/etc/java.conf'' and tweak it. But of course [[Java]] has multiplatform, not [[Unix]] roots, so no such configuration file exists, as far as I can tell. I thought configuring the default options for all [[Java]] processes is impossible. However today I realized that
<source lang="bash">
<source lang="bash">
$ java -client
$ java -client
</source>
</source>
-
works too. From here it was just a step to symlink the server directory inside the [[JDK]] installation to client:
+
works too fine as well. From that moment it was just a small step to symlink the server directory inside the [[JDK]] installation to client:
<source lang="bash">
<source lang="bash">
-
# cd jre/lib/i386/
+
$ cd jre/lib/i386/
-
# mv server/ server.bak/
+
$ mv server/ server.bak/
-
# ln -s client server
+
$ ln -s client server
</source>
</source>
Now I can use all the [[JDK]] functionality without problems. However it took me a while to get there. No surprise nobody offers [[Java]] in [[Virtualization|virtualized]] environments, when it is so hard to set it up (and [[PHP]] is instantly ready).
Now I can use all the [[JDK]] functionality without problems. However it took me a while to get there. No surprise nobody offers [[Java]] in [[Virtualization|virtualized]] environments, when it is so hard to set it up (and [[PHP]] is instantly ready).
 +
 +
Btw. this shows that [[FilesLayout|location of your files on disk]] is an important [[APITypes|type of API]] which can compensate missing presence of a configuration file.
 +
 +
==== Jan 30, 2014 update ====
 +
 +
I've run into the same problem again after switching to new [[CentOS]] 6. This time it is amd64 bit [[Virtualization|virtualized]] environment and to make things worse, the 64-bit [[Java]] does not have the ''client'' mode anymore!
 +
 +
After a lot of work and reading through sources we found out there is an [[environment]] variable that [[Java]] honors:
 +
 +
Well, it is not documented, but there is:
 +
 +
<source lang="bash">
 +
_JAVA_OPTIONS="-Xmx64M -XX:MaxPermSize=32M"
 +
export _JAVA_OPTIONS
 +
</source>
 +
 +
Still I wonder. Am I really the only person on a planet to run into such issues?

Current revision

OpenJDK is a version of JDK released under GPL (with GNU Classpath exception) open source license. OpenJDK comes with various improvements over the classical Oracle's JDK which often makes the OpenJDK much less usable than the original. One of the problems is the modified launcher parameters as described in Virtualization page. Instead of being helpful, it just makes the whole system unusable. However, at least the system starts.

For a while I've been struggling with Java on my hosted Linux (running CentOS). Whenever I tried:

$ java
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

Why? The system has a lot of resources, so where is the problem? It turned out that the workaround is easy. Just to limit the number of available memory (this by itself is ridiculous, but it shows that allowing virtualization is not the primary driver for evolution of Java technology):

$ java -mx64M
Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)

Global Configuration

The question however is: How to modify each JDK utility (jar, javac, javadoc, etc.) to use this changed setting? Usual Unix style is to locate /etc/java.conf and tweak it. But of course Java has multiplatform, not Unix roots, so no such configuration file exists, as far as I can tell. I thought configuring the default options for all Java processes is impossible. However today I realized that

$ java -client

works too fine as well. From that moment it was just a small step to symlink the server directory inside the JDK installation to client:

$ cd jre/lib/i386/
$ mv server/ server.bak/
$ ln -s client server

Now I can use all the JDK functionality without problems. However it took me a while to get there. No surprise nobody offers Java in virtualized environments, when it is so hard to set it up (and PHP is instantly ready).

Btw. this shows that location of your files on disk is an important type of API which can compensate missing presence of a configuration file.

Jan 30, 2014 update

I've run into the same problem again after switching to new CentOS 6. This time it is amd64 bit virtualized environment and to make things worse, the 64-bit Java does not have the client mode anymore!

After a lot of work and reading through sources we found out there is an environment variable that Java honors:

Well, it is not documented, but there is:

_JAVA_OPTIONS="-Xmx64M -XX:MaxPermSize=32M"
export _JAVA_OPTIONS

Still I wonder. Am I really the only person on a planet to run into such issues?

Personal tools
buy