Can any one help me with some referenes as to how I can check different values passed to the JVM. For example if I invoke the jvm with the following options "-Djava.library.path=lib", how do I check what is passed as library arguments to the JVM.
The things set by the -D flag are called sytem properties. You can retrieve them using System.getProperty. eg:
System.getProperty("java.library.path")
There are a few other methods in System that may be of interest you you, like System.getProperties which returns the entire set of system properties.
Note that there are some system properties that will have values even without being set by the -D flag.
Related
I need to create a java solution which can create/set the certain environment variable using Java Code. These new environment variable will be used by the another java program on the same machine. I found code which can create the environment variables in same process using processbuilder.
That's not how environment variables work.
Environment variables are, in essence, an extra set of parameters that is passed into a program. If that program in turns launches a new program, then it can forward its environment variables, or not, and it can set (or unset) any other environment variables, or not, in that program it's launching; but environment variables are not a global property of a machine, and there's no way for a program to send an environment variable to another program just because they're on the same machine.
Instead, you'll need for your first program to store the necessary key-value mappings in a file somewhere on the host, and your second program to read those mappings.
That said, you may find it helpful to use environment variables as part of your solution; for example, you could have your first program write the key-value mappings in a format that Bash will interpret as setting environment variables:
export foo=bar
export baz=bip
and then launch your second program using a Bash wrapper script that first pulls in the key-value mappings (source file_that_the_first_program_wrote_to.txt) and then executes it.
There is no persistence mechanism in Java for "environment variables".
This means that you have to look into other options means to persist information.
As you are talking about simple things that would fit into environment variables, the natural thing to use would be java Properties.
Meaning: you have one (or more) property files in defined places; and some of your Java programs just read those files; whereas others also might manipulate the content of those files.
I can't believe I couldn't find this on the web, I must have been using some bad search terms...
Anyway, is there any way to set some default arguments for the JVM. I'm running JRE 1.8.0_73 if it makes much difference.
The goal I am trying to achieve is attaching an agent to every instance of the JVM that starts, in this particular case an applet. I know I could start the applet from the command line and specify the arguments there but I would like to know if there is a way to globally set some command line arguments.
Thanks!
You can create a system environment variable named _JAVA_OPTIONS and set its value to all the default arguments you need to pass to the JVM.
I have searched many places of making IPv6 enabled to have a dual-stack machine IPv6.
I found many have answered to set java.net.preferIPv6Addresses=true which is set to false by default.
I want to know where exactly should I make these changes, i.e in which file or do I have to write some Java code to put this into.
The setting needs to get into the JVM's system properties ... and it needs to be there before the relevant part of the Java class library initializes.
The "bomb proof" way to do this is to pass the setting to the JVM as a command line parameter; e.g.
java -Djava.net.preferIPv6Addresses=true ... com.example.MainClass <args>
You could also code your application to inject the setting using
System.setProperty("java.net.preferIPv6Addresses", "true");
but you need to ensure that the injection happens soon enough1, and that would not be trivial.
1 - "Soon enough" means before JVM networking code's static initialization has occurred. This can be difficult to achieve in a complex application. Note the the Network Properties documentation states: "Some are checked only once at startup of the VM, and therefore are best set using the -D option of the java command ...". Note that it does NOT state that those properties can only be set that way.
The suggestion of using a JAVA_OPTS environment variable will only work for some applications. The handling of JAVA_OPTS will happen in your application's launcher or wrapper script before the JVM is launched. The same applies to _JAVA_OPTIONS ... which is one that I've not seen before.
(If the application you are using is properly documented, then its documentation should explain how to specify options that need to be passed to the java.exe launcher.)
The standard java.exe and javaw.exe commands certainly DO NOT pay any attention to the JAVA_OPTS environment variable.
you must put in in your enviorment path before running the java executable.
in linux
export JAVA_OPTS="-Djava.net.preferIPv4Stack=true" (same for ipv6 )
Hi I need to see eclipse's running configuration in a simple java project. for example print them as key value pairs at console would be enough
[EDIT]: the reason for this
I added a parameter to eclipse.ini but I'm not sure about the value whether it is passed as I expect or not
and the parameter I'm looking for is
-Dorg.eclipse.swt.browser.XULRunnerPath=xulrunner
You have two ways for getting the details
http://www.mkyong.com/java/how-to-list-all-system-properties-key-and-value-in-java/
In case it is java parameters
Read Java JVM startup parameters (eg -Xmx)
From your updated response.
I will suggest that you check your memory manager.
In windows that will be task manager
mac that will be Activity Monitor
on linux you can fire top command from command line
Still not satisfied, check over this StackOverflow thread
Monitoring own memory usage by Java application
Still not satisfied. I would suggest profiling of the application using yourkit profiler or any other java profiler.
When you start yourkit it shows the java applications running. Simply click on one of it and it will initate profiling for you.
Eclipse runs on a JVM, which is not the same JVM where your program will run.
It would be easier to find the configuration file (eclipse.ini I guess is what you are looking for), since they will not be environment settings for the JVM where your code will run.
all runtime configuration endsup being a java argument or a system property passed
so you can print all the commandline argument passed in to java + all the System properties and its values (may be with filtered set of key value based on your interest)
Is there a way to reconstruct the command line arguments passed to Java within a Java program, including the JVM options and classpath option?
I have a Java program that needs to restart the JVM and manipulate its bootclasspath (i.e. trying to override some system classes). I use the libc system method to invoke the new JVM.
I'm open for better approaches, but Java agents isn't an option.
Why not use a file that has these properties just like the Eclipse ini file and NetBeans conf files. That way you just read these properties and spawn the new Java process with these properties.
Back to your question, this previous answer should do
I agree that futzing with the bootclasspath is generally a poor idea. But...
Grab the code for "java.c" - the C program that compiles down to java.exe. You'll find that it just uses the JNI Invocation API to construct a JVM and call the main method. You could modify and re-compile this to look for particular exit codes, etc. and loop around and re-launch the JVM if required.
Alternatively, Eclipse does this (or at least used to), but having one Java program construct the command line (from a props file, etc.) and launch a sub-process. Again, it hooked the sub-process exit code and used that to decide whether or not to re-launch a new sub-process.
Err... modifying a whole core java class at runtime is a very very bad idea.
Whats wrong with subclassing here? Are you trying to modify an external library, add functionality, or be lazy?