Embedding the JRE

I have written program that I want to run on a computer that doesn't contain the Java Runtime Environment.
I am not sure how to go about this but i think it is possible by storing the JRE in a jar file along with the source code of the program, but I don't know what environment variables to use and how to implement them correctly in a batch file.

I guess you could try embedding the JRE. Here are a few pitfalls though. In general I think you're better off letting your clients install the JRE for themselves.
0. Might not work
1. Dramatically increases the size of your deliverables
2. The JRE will only be compatible with 1 OS
3. Clients won't be able to click on jar files and have them run

Similar Messages

Can I get rid of parts of the JRE for my app?

I am trying to figure out how to easily deploy a stand-alone desktop Swing application. It's more like Microsoft Word than the typical Swing business app that deals with networks and databases. I'd like to make this easily downloadable by regular people, like a 10-year old who has installed an IM client, or a 70-year old who has downloaded the latest version of a browser, i.e., just download an installation file and then click to install in the relatively standard manner in which Windows apps are installed.
What I am definitely trying to avoid is making the user go to Sun's Java distribution website, which is written by computer geeks for computer geeks. If a potential user sees that, they'll get confused, give-up, and I'll have lost a potential user.. Since a Swing application that is developed and tested using an earlier version of the JRE won't necessarily work with a later version, I can't make the assumption that as long as the latest JRE is installed on the user machine, everything is fine. As far as I can tell, I need to download a self-contained version of the JRE that I developed with in order to guarantee that the app will run as expected. I also don't want the user to have to download a 15 Mb 1.5 JRE, or the purported 50 Mb 1.6 JRE just to be able to run my little program. (I'm really starting to see why there are no popular Java desktop apps.)
So my question is - if I compile my application down into machine code from binary code, does anyone know if can I get away with running it with a stripped-down JRE? I'm wondering if I can get rid of parts of the JRE that deal with things like interpreting bytecode, networking or database access, none of which I need to worry about. Sun's legal department might not like this, but is this at all technically feasible? I'm actually happy to hear about any ideas regarding shrinking the size of the distribution. Thanks.

I voted for the enhancement request. It is almost exactly what I am concerned with.
I am a big fan of Excelsior Jet. I tried out the free version about a year-and-a-half ago, and was pretty happy with it. It was actually the only machine-code compiler I tried out of several that worked. If I ever get to the point where I can start selling my app, I expect that I'll use it. I've been checking the website every so often since then, and reading about the next version, where a JRE can be included in the distribution. That helped spark my original question. While the worry about making sure my application had the right JRE version will be solved, it still bugs me that I have to ship so much unnecessary JRE code. (I blame Sun for that, not Excelsior Jet.) I was wondering if it was at all technically feasible to strip out the unnecessary code, irrespective of the legal issues. When compiled to byte-code, my program is under 1 MB. When I compiled it to machine code under JDK 1.4, it was about 5 MB. I imagine that compiling to machine-code with the included 1.5 JRE, after compression, will result in a size in the 15-20 MB range. And this after refactoring my program to where it's about 1/3 it's original size. I'm really worried about the direction this is going, and I don't even want to think about what including the 1.6 JRE will require.
Where did you read that I've been programming Java since '97. I was a contractor at Sun between 1995 and 1997, and started working on Java 1.0 apps back then, but I don't ever remember mentioning that. If you asked because you're thinking I should know more about JVM/JRE issues, you're probably right, but I focus almost exclusively on higher-level application and GUI/Graphics issues. The deep-down Java stuff makes me break out into a cold-sweat.

Running a Java program without the JRE...

Hi there,
I was wondering whether it is possible to run my java applications on a system that does not have the JRE installed?
Is there a way to compile the java bytecode into an executable - let's say for windows.
Thank you

See:
http://www.bearcave.com/software/java/comp_java.html
Yair.

How do I specify the JRE i wish to use to Run an Application.

Hi Everyone;
Please bear with me if you read this before.
I have installed java 1.3.1 and java 1.4.1 in that order.
The JRE used by default is java 1.4.1
How do I specify the JRE I wish to use to Run an Application from a command prompt.
Example:
Java -something org.jboss.Main
help ??
Stephen

I was a lil embarrassed. I told my supervisor that the installation of java overwrites the JRE and that's that.
My supervisor took 10 minutes and went through it and found java.exe in the System32 file.
The java.exe file is found in guess where "C:/WINNT/System32/" folder how nice. C:/WINNT/System32/ is in the path. Not only that it's the first entry in the path. So when I execute java it is not using java.exe any one of the java files that I got from the java website.
So I don't have any control over the version.
Oh well;
That's life. That's 1 for my supervisor.
Stephen

Is it possible to change file name policy in the JRE cache folder?

We are getting calls from our clients complaining of slowdowns in loading our Java applet. The reason is a virusscanner. If a virusscanner is in the middle, it can drastically slow down the download process, and therefore cause some high delay before the user can work on the our product as expected.
On this csutomer's side, it may take up to 10 min (the first time it is ran) instead of 1 min. JRE 1.6 is in use.
They dont want to exclude from antivirus scan all files from Sun\Java\Deployment\cache folder.
Question:
Is it possible to change file name policy in the JRE cache to make it less unique?
Thanks,
-Dima

dgomel wrote:
We are getting calls from our clients complaining of slowdowns in loading our Java applet. The reason is a virusscanner. If a virusscanner is in the middle, it can drastically slow down the download process, and therefore cause some high delay before the user can work on the our product as expected.
On this csutomer's side, it may take up to 10 min (the first time it is ran) instead of 1 min. JRE 1.6 is in use.
They dont want to exclude from antivirus scan all files from Sun\Java\Deployment\cache folder.
Question:
Is it possible to change file name policy in the JRE cache to make it less unique?
I suggest you solve the real problem - big files.
There are two scenarios
1. Initial download
2. Updates.
The first takes as long as it takes. No way around it.
The second means that you can't use one jar. Otherwise every single update requires downloading the entire application every time. Multiple jars means only the one that changed is downloaded.

XML : Transform DOM Tree to XML String in an applet since the JRE 1.4.2_05

Hello,
I build a DOM tree in my applet.
Then I transform it to XML String.
But since the JRE 1.4.2_05 it doesn't work.
These lines failed because these variables became final:
org.apache.xalan.serialize.CharInfo.XML_ENTITIES_RESOURCE = getClass().getResource("XMLEntities.res").toString();
org.apache.xalan.processor.TransformerFactoryImpl.XSLT_PROPERTIES = getClass().getResource("XSLTInfo.properties").toString();The rest of the code :
DocumentBuilderFactory domFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = domFactory.newDocumentBuilder();
Document domXML = builder.newDocument();
// I build my DOM Tree
StringWriter xmlResult = new StringWriter();
Source source = new DOMSource(domXML);
Result result = new StreamResult(xmlResult);
Transformer xformer = TransformerFactory.newInstance().newTransformer();
xformer.setOutputProperty(javax.xml.transform.OutputKeys.INDENT,"yes");
xformer.transform(source,result);Is there any other way to get an XML String from a DOM tree in an applet ?
I'm so disappointed to note this big problem.

Does anyone have an idea why I get this error message when try to use transform in an applet?
Thanks...
java.lang.ExceptionInInitializerError
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Unknown Source)
     at org.apache.xalan.serialize.SerializerFactory.getSerializer(Unknown Source)
     at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(Unknown Source)
     at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Unknown Source)
     at matrix.CreateMtrx.SaveDoc(CreateMtrx.java:434)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at thinlet.Thinlet.invokeImpl(Unknown Source)
     at thinlet.Thinlet.invoke(Unknown Source)
     at thinlet.Thinlet.handleMouseEvent(Unknown Source)
     at thinlet.Thinlet.processEvent(Unknown Source)
     at java.awt.Component.dispatchEventImpl(Unknown Source)
     at java.awt.Container.dispatchEventImpl(Unknown Source)
     at java.awt.Component.dispatchEvent(Unknown Source)
     at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
     at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
     at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
     at java.awt.Container.dispatchEventImpl(Unknown Source)
     at java.awt.Component.dispatchEvent(Unknown Source)
     at java.awt.EventQueue.dispatchEvent(Unknown Source)
     at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
     at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
     at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
     at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.RuntimeException: The resource [ XMLEntities.res ] could not load: java.net.MalformedURLException: no protocol: XMLEntities.res
XMLEntities.res      java.net.MalformedURLException: no protocol: XMLEntities.res
     at org.apache.xalan.serialize.CharInfo.<init>(Unknown Source)
     at org.apache.xalan.serialize.SerializerToXML.<clinit>(Unknown Source)
     ... 28 more

How do you include the jre in your installs?

This is a fall back and punt question.
My organization develops desktop (Swing) Java apps. To deploy, we have an install program that first runs the JRE install that you download from Sun's web site, then we copy our own jars and data files and so on to the user system. This "two step" approach works, but it's clumsy and ugly.
How do others deploy the JRE? Do you have your customers run the JRE install themselves, automatically run it within your own install, or do you mix Sun's files in with your own and copy them all at one time? If the last, what do you do about registry entries? (As in, worrying about overwriting entries if the user has already installed a newer version of java, etc.) Are there other complications?
I guess I'll just try it and see what happens, but if anybody has some helpful hints I'd be anxious to hear them.

Instead of including the JRE install file and running it you could just include the JRE directory with your install program. (C:\Program Files\Java\j2re1.4.2_05 for example) This way you won't mess up any java installation that may already be on the target machine.
Simply start your app with a batch or .exe file using a relative path to the java/javaw command. I use the following free program along with any standard installer:
http://www.rolemaker.dk/nonRoleMaker/javalauncher/marner_java_launcher.htm

Exception trying to start the JRE Control Panel

I've run into some persistent problem with seemingly any version of the JRE on my WinXP system. Whenever I try to start the control panel, either from the Windows Control Panel UI, or from the Java system tray icon, I get an exception error:
java.lang.ArrayIndexOutOfBoundsException: 365
     at com.sun.deploy.panel.UpdatePanel.setText(Unknown Source)
     at com.sun.deploy.panel.UpdatePanel.actionPerformed(Unknown Source)
     at javax.swing.JComboBox.fireActionEvent(Unknown Source)
     at javax.swing.JComboBox.setSelectedItem(Unknown Source)
     at javax.swing.JComboBox.setSelectedIndex(Unknown Source)
     at com.sun.deploy.panel.UpdatePanel.reset(Unknown Source)
     at com.sun.deploy.panel.UpdatePanel.<init>(Unknown Source)
     at com.sun.deploy.panel.ControlPanel.initComponents(Unknown Source)
     at com.sun.deploy.panel.ControlPanel.<init>(Unknown Source)
     at com.sun.deploy.panel.ControlPanel.main(Unknown Source)
This is what happens on the first attempt after the OS has booted, and subsequent attempts just result in nothing obvious happening (no control panel, no error, nothing).
I currently have JRE 1.6.0_07-b06 installed, but this seems to be happening with any JRE version I try. I had remnants of older JRE's under C:\Program Files\java, and I went through ensuring that each was removed (if I could get rid of it via Add/Remove Applications, I used that) until I was down to zero other than the MS JVM that is inherently part of Windows. I then installed the current Sun JRE and still have the problem. :-\ So not sure what it is the JRE control panel is trying to do here, nor how to fix it other than reinstalling the OS (and I'm not that desperate, but it really is annoying).
I figure it's probably something still hanging around in the Registry (<shudder!>) and poking around under HKLM\SOFTWARE\JavaSoft, I see keys for various old versions under the \Java Plug-in, \Java Runtime Environment, and \Java Web Start keys, most of which look like references to directories or files which no longer exist on the system. Any thoughts as to whether I can just safely delete these keys as a sanity check (jeez I wish Sun had steered clear of the Registry)? What I'm wondering is since the JRE control panel (when it works :-) shows you a list of installed JREs it found, I'm wondering if these bogus versions listed in the Registry are causing the ArrayIndexOutOfBoundsException.
Any ideas are greatly appreciated. Thanks in advance!

start JRE control panel

Running the JRE from a CD

Hi all,
I'm hoping to distribute a Java application I have written on CD but the majority of the people I will be giving it to won't have the Java Runtime Environment. Is it possible to burn the JRE onto a CD along with my class files so the user can execute the program by a batch file (everyone running it will be on a Windows platform)?
Thanks.

Verrry slow, though - and some configuration files
that are normally updatable won't be - unless it's a
writable cd.Ah, how often do you update your JRE configuration on the fly?
It should be perfectly OK to just copy the "jre" directory from a standard JDK distribution into your CD, and have your startup file point to its own JRE to load Java. (You don't even have to set up CLASSPATH specially for this - the java startup code knows how to find its own rt.jar, etc.)

Using axbridge.dll without going through the JRE installation process

I've searched the web and this forum for this specific problem, and have found related items, but nothing that quite answers the question.
I have an application that uses the JRE's axbridge.dll to access a DLL created from a Java bean. I used the packager to create a DLL named MyBean.dll.
When I go through the full JRE install, everything works great. That is to say, when I execute Sun's JRE installation program and go through the normal install process, I can access the bean through MyBean.dll without any problems.
I am accessing MyBean.dll from a Visual Basic 6.0 application. Converting to VB .Net is NOT an option at this time. The VB app uses MyBean.dll for a critical part of the application.
It is my understanding that it is not strictly necessary to go through the full JRE installation process. Simply deploying the JRE by copying its directory (and all subdirectories) to your application's directory structure should be sufficient. This would be HIGHLY desirable for my application. In fact, if I can't do this, it may be a show-stopper.
When I install my application in this way (i.e, by simply copying the JRE instead of "installing" it) it doesn't work at all. I immediately get an error saying that the executable "has encountered a problem and needs to close. We are sorry for the inconvenience" and a dialog is displayed offering to send the problem information to Microsoft.
The details indicate clearly that the problem occurs in the axbridge.dll, version 1.4.2.60.
1. Any ideas on how to get the axbridge.dll to work without going through the full JRE install?
2. Are there any alternatives to using the axbridge.dll to get my VB app to be able to use the Java? Remember, it is VB that must call the Java, NOT the other way around.
3. Is JNI an alternative? If so, can I use JNI to get VB to use Java, or do I have to write the DLL's in C++?
Any help you can give would be VERY MUCH appreciated.

I'm also on a JRE installation problem with the bridge.
Here is a regmon extract on excel using a dll that uses a java-packaged dll from the bridge:
5229 5.69504923 EXCEL.EXE:2364 QueryValue HKCR\CLSID\{9DD49FCD-BB61-414E-88C8-E6F5B35AEDCB}\InprocServer32\(Default) SUCCESS "C:\win32app\Specific\jre1.5.0_05\bin\axbridge.dll" << The axbridge dll in a specific location
5271 5.70646800 EXCEL.EXE:2364 QueryValue HKLM\SOFTWARE\JavaSoft\Java Plug-in\1.5.0_05\JavaHome SUCCESS "C:\Program Files\Java\jre1.5.0_05" << an installed JRE 1.5.0
This is confirmed with process explorer : excel is using "C:\Program Files\Java\jre1.5.0_05\lib\rt.jar" and not "C:\win32app\Specific\jre1.5.0_05\lib\rt.jar"
In other word, the axbridge check for its installation location in the registry to know where to start.
Even if all your components have been updated in the registry as suggested here : http://forum.java.sun.com/thread.jspa?forumID=40&threadID=559704
JRE Bug or feature?
Anyway the registry is evil.

Pkg com.sap.aii.proxy.framework.core don't exist even added in the JRE path

Hi All,
I am facing some error while activating the activity. I have checked-in the activity but getting the error while trying to activated the activity. there are two DC's in one of them i am gettign this error. i have not noticed this while check-in.
After checked in - i am not getting the any such option --Revert activitty or delete activity.
This activity is alreday closed.. what i can do with this activity?? After this error i am not able to activate any activity. I am getting the below error in all the activity.
package com.sap.aii.proxy.framework.core does not exist even though i have added this into the JRE path in NWDS. Do i need to import the same version file somewhere into J2ee server or somewhere else??
Regards,
Narpal

Hi,
javac ERROR: class file has wrong version 49.0, should be 48.0
This error means that the class file in question is being built with JDK1.5 (49), however it should be built with JDK1.4.2 (48).
In other words, as per the class the build expects a class file built with 1.4.2, but in your track JDK1.5 is configured for the build tool.
You need to therefore :
A.) review the CBS service settings, as most likely the parameters BUILDT_TOOL_JDK_HOME and JDK_HOME_PATHS are set up improperly.
B.) plus the build variant is incorrect in the track in question.
I'll refer below to the corresponding points with the letters A and B.
Some more explanation on the error:
If you check any class file with a hex editor, you'll see at the beginning of it this:
example: CA FE BA BE | 00 00 |00 31 ...
JDK 1.6 = 50 (0x32 hex)
JDK 1.5 = 49 (0x31 hex = (161)*3 + (160)*1 = 49)
JDK 1.4 = 48 (0x30 hex)
JDK 1.3 = 47 (0x2F hex)
JDK 1.2 = 46 (0x2E hex)
JDK 1.1 = 45 (0x2D hex)
On the first 4 bytes there's a magic number (CAFEBABE) which ensures this is a java class file, then on 2-2 bytes you'll see the minor and the major version (in this order). In the above example 00 00 | 00 31. This is what displayed as major.minor i.e. 49.0 what you can see in error messages. See also the attachment I've put to this thread minormajor.JPG.
More information on the class file structure:
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html
For point A)
See the guide for doublechecking the CBS parameters
help.sap.com u2013 CBS Service Properties
http://help.sap.com/saphelp_nw70/helpdata/EN/53/75b3407e73c57fe10000000a1550b0/frameset.htm
Further explanation to the paramters
BUILD_TOOL_JDK_HOME and JDK_HOME_PATHS
BUILD_TOOL_JDK_HOME = <path to highest JDK>
JDK_HOME_PATHS = JDK1.3.1_HOME=<path of jdk131>;JDK1.4.2_HOME=<path of jdk142>;JDK1.5.0_HOME=<path of jdk150>JDK1.6.0_HOME=<path of jdk160>;default=<path of the JDK as default>
Some simple rules with examples:
- for BUILD_TOOL_JDK_HOME you simply enter the path to your JDK, e.g.: /opt/IBMJava2-amd64-142
- for JDK_HOME_PATHS you have to follow the scheme "key=value" e.g.: JDK_1.4.2_HOME=/opt/IBMJava2-amd64-142
- for BUILD_TOOL_JDK_HOME you always specify the highest JDK,
- for JDK_HOME_PATHS you list the available JDKs.
- JRE is not allowed, specify always JDK!
For point B)
Regarding the build variant in your track: check the page 13 for the paramter com.sap.jdk.home_path_key as per the guide :
How To... Setup an NWDI Track for Composition Environment Developments
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7014086d-3fd9-2910-80bd-be3417810c6f
Summary:
A. The first part of the solution is then to doublecheck the CBS service parameters. CBS service must be restarted after changes.
B. The second part is to doublecheck the build variant in the track (see the Build Variants tab on the Track Data tab on the CMS webui - Landscape Configurator).
I recommend you to have
A) BUILD_TOOL_JDK_HOME = <highest available JDK, I recommend here to set the path to JDK1.5>
JDK_HOME_PATHS = JDK1.4.2_HOME=<path of jdk142>;JDK1.5.0_HOME=<path of jdk150>;default=<path of the JDK as default, set it to the same path as you did for 1.4.2_HOME>
B) set the com.sap.jdk.home_path_key in the build variant to 1.4.2_HOME, or leave it for the default. Do not forget to set this build variant explicitly for >= 7.1 tracks to JDK1.5.0_HOME
I hope this helps.
Best Regards,
Ervin

It is possible to include the jre(not the installer) with the application?

Is it possible to include the jre(not the installer) with the application, so that the application will run on its own jre.??
If so please provide me instructions,how to do it.
Thanks
Isma

See http://java.sun.com/javase/6/docs/technotes/guides/deployment/index.html

Attn: Sun. Can we distribute the JRE with a program we write?

I'm trying to find out whether it's legal to distribute the JRE with a program I write. If you look at the license agreement when you download the JRE, first it has the regular license agreement, which says that you can't. But then it has the "supplemental" license agreement (and it says that this "modifies" the regular license agreement). In section 2 of the supplemental license agreement, it quite clearly states that you can as long as you don't modify it and you include some little messages in your documentation.
So I'm hoping to get an answer from someone who actually works for Sun. It seems pretty clear to me that we ARE allowed to distribute the JRE with a program, but people keep sending me emails when I tell them about it - saying things like "You can't program in Java because you can't distribute it."
What I want to do is have an installation program that installs my game and then installs Java (with Sun's JRE installer - this is included ONLY so that it can run my game, as stated in the supplemental license agreement). I should also mention that I do actually intend to SELL this program, so if that's a problem, please say so. Anyways, could someone from Sun tell me whether this is allowed or not? I don't want to break the law.
- Steve Fletcher

The JRE includes a readme file that explicitly states that distribution is permissible, given certain conditions. In particular, look at the 1st paragraph below:
Reproduced here:
README
Java(TM) 2 Runtime Environment, Standard Edition
Version 1.4.1
The Java(TM) 2 Runtime Environment is intended for software developers
and vendors to redistribute with their applications.
The Java 2 Runtime Environment contains the Java virtual machine,
runtime class libraries, and Java application launcher that are
necessary to run programs written in the Java programming language.
It is not a development environment and does not contain development
tools such as compilers or debuggers. For development tools, see the
Java 2 SDK, Standard Edition.
=======================================================================
Deploying Applications with the Java 2 Runtime Environment
=======================================================================
When you deploy an application written in the Java programming
language, your software bundle will probably consist of the following
parts:
Your own class, resource, and data files.
A runtime environment.
An installation procedure or program.
You already have the first part, of course. The remainder of this
document covers the other two parts. See also the Notes for Developers
page on the Java Software website:
http://java.sun.com/j2se/1.4.1/runtime.html
Runtime Environment
To run your application, a user needs the Java 2 Runtime Environment,
which is freely available from Sun for application developers to
redistribute.
The final step in the deployment process occurs when the software is
installed on individual user system. Installation consists of copying
software onto the user's system, then configuring the user's system
to support that software. You should ensure that your installation
procedure does not overwrite existing JRE installations, as they may
be required by other applications.
=======================================================================
Redistribution of the Java 2 Runtime Environment
=======================================================================
The term "vendors" used here refers to licensees, developers, and
independent software vendors (ISVs) who license and distribute the
Java 2 Runtime Environment with their programs.
Vendors must follow the terms of the Java 2 Runtime Environment Binary
Code License agreement.
Required vs. Optional Files
The files that make up the Java 2 Runtime Environment are divided into
two categories: required and optional. Optional files may be excluded
from redistributions of the Java 2 Runtime Environment at the
licensee's discretion.
The following section contains a list of the files and directories that
may optionally be omitted from redistributions with the Java 2 Runtime
Environment. All files not in these lists of optional files must be
included in redistributions of the runtime environment.
Optional Files and Directories
The following files may be optionally excluded from redistributions:
lib/charsets.jar
Character conversion classes
jre/lib/ext/
sunjce_provider.jar - the SunJCE provider for Java
Cryptography APIs
localedata.jar - contains many of the resources
needed for non US English locales
ldapsec.jar - contains security features supported
by the LDAP service provider
dnsns.jar - for the InetAddress wrapper of JNDI DNS provider
bin/rmid
Java RMI Activation System Daemon
bin/rmiregistry
Java Remote Object Registry
bin/tnameserv
Java IDL Name Server
bin/keytool
Key and Certificate Management Tool
bin/kinit and jre/bin/kinit
Used to obtain and cache Kerberos ticket-granting tickets
bin/klist and jre/bin/klist
Kerberos display entries in credentials cache and keytab
bin/ktab and jre/bin/ktab
Kerberos key table manager
bin/policytool
Policy File Creation and Management Tool
bin/orbd
Object Request Broker Daemon
bin/servertool
Java IDL Server Tool
In addition, the Java Web Start product may be excluded from
redistributions. Depending on the platform, the Java Web Start
product is contained in a file named as follows. The actual
product version number would replace the <version number> notation.
javaws-<version number>-solaris-sparc-i.zip
javaws-<version number>-solaris-i586-i.zip
javaws-<version number>-linux-i586-i.zip
javaws-<version number>-windows-i586-i.exe
Redistribution of Java 2 SDK Files
The limited set of files from the SDK listed below may be included in
vendor redistributions of the Java 2 Runtime Environment. All paths
are relative to the top-level directory of the SDK.
- jre/lib/cmm/PYCC.pf
Color profile. This file is required only if one wishes to
convert between the PYCC color space and another color space.
- All .ttf font files in the jre/lib/fonts directory. Note that the
LucidaSansRegular.ttf font is already contained in the Java 2
Runtime Environment, so there is no need to bring that file over
from the SDK.
- jre/lib/audio/soundbank.gm
This MIDI soundbank is present in the Java 2 SDK, but it has
been removed from the Java 2 Runtime Environment in order to
reduce the size of the Runtime Environment's download bundle.
However, a soundbank file is necessary for MIDI playback, and
therefore the SDK's soundbank.gm file may be included in
redistributions of the Runtime Environment at the vendor's
discretion. Several versions of enhanced MIDI soundbanks are
available from the Java Sound web site:
http://java.sun.com/products/java-media/sound/
These alternative soundbanks may be included in redistributions
of the Java 2 Runtime Environment.
- The javac bytecode compiler, consisting of the following files:
bin/javac [Solaris(TM) Operating Environment
and Linux]
bin/sparcv9/javac [Solaris Operating Environment
(SPARC(TM) Platform Edition)]
bin/javac.exe [Microsoft Windows]
lib/tools.jar [All platforms]
- jre\bin\server\
On Microsoft Windows platforms, the Java 2 SDK includes both
the Java HotSpot Server VM and Java HotSpot Client VM. However,
the Java 2 Runtime Environment for Microsoft Windows platforms
includes only the Java HotSpot Client VM. Those wishing to use
the Java HotSpot Server VM with the Java 2 Runtime Environment
may copy the SDK's jre\bin\server folder to a bin\server
directory in the Java Runtime Environment. Software vendors may
redistribute the Java HotSpot Server VM with their
redistributions of the Java Runtime Environment.
Unlimited Strength Java Cryptography Extension
Due to import control restrictions for some countries, the Java
Cryptography Extension (JCE) policy files shipped with the Java 2 SDK,
Standard Edition and the Java 2 Runtime Environment allow strong but
limited cryptography to be used. These files are located at:
<java-home>/lib/security/local_policy.jar
<java-home>lib/security/US_export_policy.jar
where <java-home> is the jre directory of the Java 2 SDK or the
top-level directory of the Java 2 Runtime Environment.
An unlimited strength version of these files indicating no restrictions
on cryptographic strengths is available on the Java 2 SDK web site for
those living in eligible countries. Those living in eligible countries
may download the unlimited strength version and replace the strong
cryptography jar files with the unlimited strength files.
Endorsed Standards Override Mechanism
An endorsed standard is a Java API defined through a standards
process other than the Java Community Process(SM) (JCP(SM)). Because
endorsed standards are defined outside the JCP, it is anticipated that
such standards will be revised between releases of the Java 2
Platform. In order to take advantage of new revisions to endorsed
standards, developers and software vendors may use the Endorsed
Standards Override Mechanism to provide newer versions of an endorsed
standard than those included in the Java 2 Platform as released by Sun
Microsystems.
For more information on the Endorsed Standards Override Mechanism,
including the list of platform packages that it may be used to
override, see
http://java.sun.com/j2se/1.4.1/docs/guide/standards/
Classes in the packages listed on that web page may be replaced only
by classes implementing a more recent version of the API as defined
by the appropriate standards body.
In addition to the packages listed in the document at the above
URL, which are part of the Java 2 Platform, Standard Edition
(J2SE(TM)) specification, redistributors of Sun's J2SE
Reference Implementation are allowed to override classes whose
sole purpose is to implement the functionality provided by
public APIs defined in these Endorsed Standards packages.
Redistributors may also override classes in the org.w3c.dom.*
packages, or other classes whose sole purpose is to implement
these APIs.
Copyright 2003 Sun Microsystems, Inc., 4150 Network Circle,
Santa Clara, California 95054, U.S.A. All rights reserved

How to use the JRE included in the installed dir??

In windows, Id like to just bundle the JRE directory with my application, for example if the app is installed in
F:\MyApps\MyJavaProgram the jre dir will be in
F:\MyApps\MyJavaProgram\jre
but how do i get the main program to use this jre only?
thanks

But what about when the system you are using (in this case Windows) doesn't have JRE installed on and you are using native executables? You cannot type "java" when you haven't got Java on your system and in native executables case you just type the executables filename.
Install Anywhere includes the whole "jre" folder (excluding some unneeded files) in the installation package and it is copied to program folder during the installation. The program then uses that JRE when it is run. I metion again that I don't want to use Install Anywhere.
So, how can you make the programs native executable use the JRE copied (by hand) in the program's folder?

How do I know which is the correct location of the JRE?

How do I know which is the correct location of the JRE / JVM? What do I add to my PATH environment variable? I'm trying to install Sybase ASE on my Sun Fire v480 SPARC box, but keep getting the below error...
"A suitable JVM could not be found. Please run the program again using the option -is:javahome <JAVA HOME DIR>"
So I did the following...
STEP 01) To confirm that Java is installed, I ran the java -version command. I received the following output...
bash-3.00# java -version
java version "1.5.0_17"
Java(TM) Platform, Standard Edition for Business (build 1.5.0_17-b04)
Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode)
STEP 02) Then I tried to locate the location of where Java was installed...
bash-3.00# which java
/usr/bin/java
STEP 03) Then I tried to confirm if it was a symbolic link or not...
bash-3.00# ls -al /usr/bin/java
lrwxrwxrwx 1 root other 16 Jun 24 01:54 /usr/bin/java -> ../java/bin/java
STEP 04) The symbolic link doesn't seem to match any of the output below. Which is the correct location / path of Java (JVM / JRE)?
bash-3.00# find / -name java -print;
/usr/share/lib/java
/usr/share/java
/usr/bin/java
/usr/sfw/include/mozilla/java
/usr/include/firefox/java
/usr/jdk/instances/jdk1.5.0/bin/java
/usr/jdk/instances/jdk1.5.0/bin/sparcv9/java
/usr/jdk/instances/jdk1.5.0/jre/bin/java
/usr/jdk/instances/jdk1.5.0/jre/bin/sparcv9/java
/usr/jdk/packages/javax.help-2.0/doc/api/com/sun/java
/usr/java
/usr/apache/tomcat/webapps/tomcat-docs/catalina/docs/api/org/apache/naming/java
/usr/apache/tomcat55/classes/org/apache/naming/java
/usr/apache/jserv/docs/api/org/apache/java
/usr/j2se/bin/java
/usr/j2se/bin/sparcv9/java
/usr/j2se/jre/bin/java
/usr/j2se/jre/bin/sparcv9/java
/usr/appserver/samples/blueprints/adventure1.0.4/project/apps/activitysupplier/activitysupplier-ejb/src/java
/usr/appserver/samples/blueprints/adventure1.0.4/project/apps/airlinesupplier/airlinesupplier-ejb/src/java
/usr/appserver/samples/blueprints/adventure1.0.4/project/apps/bank/bank-ejb/src/java
/usr/appserver/samples/webservices/security/web/apps/clientCert/clientCert-share/src/java
/usr/appserver/samples/webservices/security/web/apps/clientCert/clientCert-war/src/java
/usr/appserver/samples/webservices/security/web/apps/xms/xms-client/src/java
/usr/appserver/samples/webservices/security/web/apps/xms/xms-share/src/java
/usr/appserver/samples/webservices/security/web/apps/xms/xms-war/src/java
/usr/appserver/samples/xml/apps/dom/src/java
/usr/appserver/samples/xml/apps/sax/src/java
/usr/appserver/samples/xml/apps/xslt/src/java
/opt/staroffice8/share/Scripts/java

I've been racking my head against the wall, but can't seem to find the solution... I've even installed the latest JRE (in a new location), but still seem to have the same problem. Please see the notes below...
I installed the latest JRE in /export/home/jvm/jre1.6.0_17/
bash-3.00# /export/home/jvm/jre1.6.0_17/bin/java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
bash-3.00# PATH=/export/home/jvm/jre1.6.0_17/bin:$PATH
bash-3.00# export PATH
bash-3.00# echo $PATH
/export/home/jvm/jre1.6.0_17/bin:/usr/sbin:/usr/bin
bash-3.00# JAVA_HOME=/export/home/jvm/jre1.6.0_17/bin
bash-3.00# export JAVA_HOME
bash-3.00# echo $JAVA_HOME
/export/home/jvm/jre1.6.0_17/bin
bash-3.00# env
HZ=100
LC_MONETARY=en_CA.UTF-8
TERM=xterms
SHELL=/sbin/sh
LC_NUMERIC=en_CA.UTF-8
OLDPWD=/export/home/jvm/jre1.6.0_17
PATH=/export/home/jvm/jre1.6.0_17/bin:/usr/sbin:/usr/bin
MAIL=/var/mail/root
LC_MESSAGES=C
LC_COLLATE=en_CA.UTF-8
PWD=/export/home/jvm/jre1.6.0_17/bin
JAVA_HOME=/export/home/jvm/jre1.6.0_17/bin
EDITOR=vi
TZ=Japan
SHLVL=1
HOME=/
LOGNAME=root
LC_CTYPE=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
_=/usr/bin/env
bash-3.00# cd /cdrom/disc1050709/
bash-3.00# ./setup -console
InstallShield Wizard
Initializing InstallShield Wizard...
Searching for Java(tm) Virtual Machine...
.........................A suitable JVM could not be found. Please run the program again using the option -is:javahome <JAVA HOME DIR>
Is there something I'm missing?
Thank you

Embedding the JRE

Similar Messages

Maybe you are looking for