JRE 1.3.1 VS. JRE 1.4.1

Hello,
I'm having trouble with an applet talking to a servlet. Behind a firewall, in JRE 1.3.1, I get AccessControlExceptions, but with 1.4.1, everything works great. All Plug-In settings for things like proxies are the same. Is there a difference between the runtimes as far as security that I don't know about?
Any help on this matter would be great.
Thanks!

jdk 1.4.0 is updated extremely so the answer is prbably yes though im not sure

Similar Messages

JRE 1.3.0 to JRE 1.4.2 Mouse related changes

My application developed in JRE 1.3.0 shows quirky behaviour when using JRE 1.4.2 to run. The mouse focus goes to a text box unnecessarily. Was there any event handling change with respect to mouse done between JRE 1.3.0 to JRE 1.4.2? has anyone faced similar problems ? Kindly hlep me....

I have a dialog box which has a textbox to enter quantity. Previously when i use JRE 1.3.0, I will enter quantity, then click 'ok'. When I click ok, another uneditable text box will display total amount and the dialog box will close. there is a taxtbox between amount textbox and ok button to enter comments. It is not mandatory and usually left blank. Now, with JRE 1.4.2, When i enter the quantity and click ok, total amount is displayed and the cursor focus goes to the comments textfield. and the dialog box is not closed. when i click ok again, the dialog box is closed. this is the scenario.

Major difference between JRE 1.4.2_13 and JRE 1.4.2_17

Can anyone pls tell me the major diff betwenn two JRE versions.
1) JRE 1.4.2_13
2) JRE 1.4.2_17
Currenly my application is using 1.4.2_13 and now we have to use 1.4.2_17.

Those are update releases. Check the release notes. See also
http://java.sun.com/j2se/1.4.2/ReleaseNotes.html#142_17
http://java.sun.com/j2se/1.4.2/ReleaseNotes.html#142_16
http://java.sun.com/j2se/1.4.2/ReleaseNotes.html#142_15
http://java.sun.com/j2se/1.4.2/ReleaseNotes.html#142_14

Why cant i run my applet on JRE 1.6 but on JRE 1.5?

Hello,
I know this is a very basic problem, but i still cannot get a justified answer for this problem. Its like i have an applet which is compiled in JDk j2sdk1.4.2_16. Now when i try to run this applet on my IE under jre 1.5.* family on all the client machines it works fine. But when i switch to jre 1.6.* family, i see the applet being displayed, but i cannot perform any operations on it i no mouse clicks work and i cannot open any file menu or my jdialog boxes.
Is it because of the incompatibilities in jre 1.6, but wont it be backward compatible to that older version applets can run on this new jre. My applet seems to be a simple applet,with only one exception that it has lot of jframes and jpanel in it.
This problem is killing me ..
Can someone point me towards where can i find what all changes are made in JRE 1.6 over JRE 1.5 so that atleast i can compare what is causing my applet freeze in JRE 1.6.
i went through the release notes but cant find anything useful there.
Please help.

Sun ensures that newer versions of the JRE are backward compatible. Your applet should work under the newest JRE version. Have you tried running the applet in a different browser (e.g., Firefox) with JRE 1.6 to eliminate it being an IE issue?

Applet runs with jre 1.5 but not jre 1.6

I'm working on an applet which works just fine when 1.5.0_15 is the latest JRE installed on the PC, but does not work when 1.6.0_6 is installed. In the latter case, the applet does not load due to getting a NoClassDefFoundError. Here's the Java Console error trace:
java.lang.NoClassDefFoundError: com/hp/nonstop/hsc/core/configuration/ConfigurationMetaData
        at com.hp.nonstop.hsc.tools.configurator.ConfiguratorApplet.init(ConfiguratorApplet.java:53)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: com.hp.nonstop.hsc.core.configurati
on.ConfigurationMetaData
        at sun.applet.AppletClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.applet.AppletClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
        ... 3 moreThe relevant (I think) portions of the <object> generated by the JSP is:
<object
    classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
    name="ConfiguratorApplet" width="600" height="400"
    codebase="http://java.sun.com/products/plugin/1.3/jinstall-131-win32.cab">
<param name="java_code" value="com.hp.nonstop.hsc.tools.configurator.ConfiguratorApplet.class">
<param name="java_codebase" value="/HSC/configurator">
<param name="java_archive" value="configurator.jar,../lib/configapi.jar,<<other jar files listed here>>">
<<other param tags included here>>
</object>The class it can't seem to find (under 1.6) is actually located in the configapi.jar file, which itself is located in the ../lib folder (relative to the /HSC/configurator folder where configurator.jar is located).
Obviously, when the browser is using JRE 1.5.15 the VM engine can find all the needed classes as the applet runs OK. But when 1.6.6 is installed, things can't be found. I suspect something different in the search paths (though I thought the "java_archive" value was supposed to specify that), in the permissions needed to read the files, or something, but I just can't track down what the difference is (and thus why things are failing with 1.6 installed).
Any help/ideas would be greatly appreciated!

Stephen.Thomas wrote:
have [you] tried moving the configapi.jar into the same folder as the configurator.jarYes, I have. I've also tried re-rooting the page to the lib directory where everything exists; i.e. changing java_codebase to /HSC/lib and changing java_archive so all jars referenced no longer have ../lib/ in them. Same behavior.
It's almost as if the search path is behaving differently between 1.5 and 1.6, possibly not even being controlled by the values of java_codebase and java_archive at all.

HTML Converter vs. JRE 1.4.x and JRE 1.3.x

Had Netscape 6.1 and IE 5.0 and JRE 1.3.1 -- wrote applet
and used HTML Converter to convert the HTML page to use JRE 1.3.1
plugin.
Everything worked just fine...
Installed Netscape 7.02 and IE 6.0 and JRE 1.4.1.
Now the HTML pages that were converted don't work with NN7 anymore
because the page wants to load the 1.3.1 plugin. I get a message to
load the 1.3.1 plugin. When I got the latest JRE, it was 1.3.1_07.
I installed it and it still won't run because it doesn't install into
NN7.
And now NN6 won't run the old page anymore because the 1.3.1_07 is the
new default plugin.
Now NN7 and 1.4.x doesn't need converted HTML pages anymore but
I still have a bunch of old converted HTML pages. Do I have to
replace all my old converted HTML pages with plain vanilla pages now?
If so, WHY DID SUN LEAD ME DOWN THE GARDEN PATH WITH THE HTML CONVERTER?
ARRGGGGHHHHHH!
Is there any way to get compatibility with the old converted HTML pages?
Ken

I don't pretend to be able to resolve the problem here - you have too many variables in the problem. The best advice I can give is to research the Plugin Developer's Guide, as it discusses this stuff in intimate detail.
http://java.sun.com/j2se/1.4.1/docs/guide/plugin/developer_guide/contents.html
These might also be useful
http://java.sun.com/products/plugin/
http://java.sun.com/products/plugin/versions.html

Jre 1.4.1_02 and jre 1.4.2_05

Help,
I have one third party application requiring jre 1.4.1_02 plug-in and another third party application requiring jre 1.4.2_05 plug-in running on a Windows 2000 Professional PC. Is there any way to get the two JAVA plug-ins to work together without requiring a re-installation of either of the plug-in?

I think you can use JRE 1.4.2_05 instead of using both. JREs there is compatibility for both JRE. Try using only one ie 1.4.2_05.

Still use JRE 1.5 even though JRE 1.4.2 is checked in IE

Hi all,
I have JRE 1.4.2 and 1.5 on my Windows XP SP 2. I want to force Internet explorer to use JRE 1.4.2 (how to: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/jcp.html).
JRE 1.4.2 is checked in Internet Explorer.
It sounds like IE still use JRE 1.5 when I test it (http://www.java.com/en/download/help/testvm.xml)... any suggestion????

See http://forum.java.sun.com/thread.jspa?forumID=32&threadID=690552

Install JRE w/o removing other JREs

I am building a Java application to be deployed on servers that live on an isolated network (i.e. not on the internet). I have very little information about the configuration of these machines, other than the OS which is XP, so I want to bundle a JRE installer in my application installer. I downloaded the latest JRE installer, jre-6u17-windows-i586.exe, to see if it could be installed from the command line or batch script. No problem with this. My issue is that the JRE uninstalls any existing versions of the 1.6 JRE. This may cause problems for existing applications on the workstations. How can I install the JRE without removing other JREs?

Gilli61 if you don't have a qualifying previous version then it would not be possible to install the upgrade. For the best assistance, I recommend our chat support at http://adobe.ly/tuMwkC. Our chat representatives can provide a personalized experience to resolve the issue you have described.

Applet work with JRE 7_51 but NOT with JRE 7_45

Hello,
My major problem is, that my Applet signed with COMODO certificate DOES NOT WORK with JRE 7_45.
The SAME applet works fine with JRE 7_45, if I sign this applet WITH A SELFMADE UNTRUSTED certificate.
WHY the comodo signed applet doesn't run in JRE 7_45 ???
If i launch the comodo signed applet with JRE 7_51 it works perfect !!!
But in our company we got JRE 7_45 and I have to deal with JRE 7_45. That’s my problem.
Could you please tell me a solution what I have to do that the comodo signed applet works also in JRE 7_45.
Thank you!
Philipp

Thanks gimbal2.
I agree the problem may be in the proxy or in the firewall but I don' to know how to prove it as if i call the servlet url from browser I dont have problems .
The version im using is 6.45 but im sure the same problem occurs also with other versions of JRE6 .
... and the problem disappear with JRE7 ...
trouble is my company want people to use JRE6
any idea ?
Gio

JRE 1.4 vs. JRE 1.3

Hi out there,
We have a very complex Java Application running on JRE1.3. Cause we're using a lot of (big) JTables I thought I try running it with JRE 1.4 'cause of the wheel mouse support.
I just replaced to the runtime versions and it did work surprisingly. My first impression was quite good 'cause I could scroll with the wheel.
But then I realised all the other things that have changed:
- The font has changed completely. Much smaller and looks terrible.
- The JComboboxes are empty at startup (no item selected), in 1.3 there was always the first item selected
- The line PrinterJob printJob = PrinterJob.getPrinterJob(); causes a NullPointerException
... Probabely there are many more differences which I couldn't see in five minutes.
What's the reason for that? Do I have to change my code and adjust it to every new runtime version or are there other ways to get around it?
Has anyone had some experience with that?
Thanks
Jonas

I am not a professional programmer and I deal with Java only since 6 months. I've experienced some similar problems (I use Windows 98 SE):
1. - JBuilder 5 personal doesn't work properly with JRE 1.4.0 and SDK 1.4.0 (design modus is not working at all, also some null pointer errors) but the programm compiles with warnings. With JRE 1.4.0 and SDK 1.3.1 or SDK 1.3.0 there is no problem. With JRE 1.3.1 there are also no problems.
2.- Jext editor doesnt work properly with JRE 1.4.0. This problem is adressed in mailing list on Source Forge as bug with JRE 1.4, but it doesn't claim it's Sun's bug. The autor is reprogramming the app. to work with JRE 1.4.0.
3. - In Jython mailing list on Source Forge some people complained about Java 1.4.0, I can not remember why, and there are some other shy complains on comp.lang.java.** about other applications.
I must say again, I am not a professional programer, and I shouldn't make hard statements, but it seems that there is no guarantie that application compiled with 1.3.1 will run properly with JRE 1.4.0. I feel this is a serious issue. Imagine I buy some application, and then I have to stick with same runtime, in order for that application to run. It is easy to change SDK on my computer, but not JRE. I am also suprised that everything is so quiet in this matter.
Marijan Tadin

JRE 1.6 upgrage from JRE v1.4.2.05 and JRE v1.5.0.04

I am currently looking to update all the PCs in a company to JRE 1.6.
looking at the link
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/properties.html
There are two files that control how JRE is configured during configuration; these files are called deployment.config and deployment.properties.
Can someone tell me firstly are these files needed for version 1.6
If so, do they working in the same way and what are the recommended settings for a silent installation to all PCs
thanks

Hey lynchmob,
Try these steps to correct the problem, you need to be logged in as an administrator:
1. Go to the group policy editor. You can get they by typing gpedit.msc into the Run dialog.
2. Navigate to computer configuration->administrative templates->windows components->internet explorer.
3. Disable "make proxy settings per-machine (rather than per-user)".
4. Login with the user account and go to Internet Options.
5. Go to the Connection tab.
6. Click on the Lan Settings button.
7. You may notice that the proxy settings are not correct. Change the proxy settings to be whatever is required for your proxy.
8. Configure Java to use browser proxy settings.
9. Open the java console.
10. Set debug level to 5.
11. Press 'p' to reload proxy settings. Use the trace messages to verify correct proxy settings were loaded.

Problem launching e-biz forms using Java JRE 1.6.0_07 and JRE 1.6.0_13

Got a problem launching Forms from e-biz 11.5.10.2 using JRE 1.6.
Our setup :
E-biz: 11.5.10.2
Forms: 6i Patchset 19
DB: 10.2.0.3
JRE: 1.6.0_07 (e-biz is config to use this version)
on windows desktop clients:
JRE: 1.6.0_13
As a non-privileged user account on the workstation, users cannot launch the forms using the 1.6.0_13 JRE.
When a privilieged(Admin) user account logs in, the forms launch fine using 1.6.0_13.
We understand that IA enforces many policy settings in our environment, but can anyone identify which types of policy settings would break this access?
Thanks everyone!
Gabe

Thanks for the docs! We've reviewed them, and are satisfied that the JRE family of 1.6 is working properly.
Our issue is that there are some windows security policies/ maybe group policies, that are restricting the launching of the forms using the newer 1.6.0_13 JRE. This is what we are after, and I would like to know if anyone else has faced similar issue.
Some more clarification:
if the workstation has the 1.6.0_07 JRE, and a non-privileged account logs in, the forms launch fine.
Once 1.6.0_13 is pushed (as our NetAdmin is requesting), the non-privileged account cannot launch forms. Instead, they get an active X request to install 1.6.0_07, which they do not have privilege to install.
Hope this helps.
Gabe

JRE 1.5 VS. JRE 1.6 - Could not convert socket to TLS

I have an applet that is trying to send an email through an SMTP server. It works just fine 1.6 but on 1.5 it blows up and I'm kind of at the end of my rope. Any help here would be great.
I've had to set up the DummySSLSocketFactory as described in the JavaMail readme but still no luck on 1.5.
Here is the error:
DEBUG: setDebug: JavaMail version 1.4ea
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc.]
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: trying to connect to host "mail.bluebottle.com", port 25, isSSL false
220 fe0.bluebottle.com ESMTP Sendmail 8.13.1/8.13.1; Thu, 28 Jun 2007 08:25:34 -0700
DEBUG SMTP: connected to host "mail.bluebottle.com", port: 25
EHLO CC-FRED
250-fe0.bluebottle.com Hello 207-174-73-129.officepartners.us [207.174.73.129] (may be forged), pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
DEBUG SMTP: Found extension "ENHANCEDSTATUSCODES", arg ""
DEBUG SMTP: Found extension "PIPELINING", arg ""
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "SIZE", arg ""
DEBUG SMTP: Found extension "DSN", arg ""
DEBUG SMTP: Found extension "AUTH", arg "LOGIN PLAIN"
DEBUG SMTP: Found extension "STARTTLS", arg ""
DEBUG SMTP: Found extension "DELIVERBY", arg ""
DEBUG SMTP: Found extension "HELP", arg ""
STARTTLS
220 2.0.0 Ready to start TLS
javax.mail.MessagingException: Could not convert socket to TLS;
nested exception is:
                java.net.SocketException: com.cc.util.controller.email.DummySSLSocketFactory
                at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:1230)
                at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:378)
                at javax.mail.Service.connect(Service.java:275)
                at javax.mail.Service.connect(Service.java:156)
                at javax.mail.Service.connect(Service.java:176)
                at com.cc.util.discovery.DiscoveryService.sendViaSMTP(DiscoveryService.java:422)
                at com.cc.util.discovery.DiscoveryService.discoverSMTPService(DiscoveryService.java:378)
                at com.cc.util.discovery.DiscoveryService.discoverPOP3Service(DiscoveryService.java:330)
                at com.cc.util.discovery.DiscoveryService.checkEmailService(DiscoveryService.java:126)
                at com.cc.applet.CCNonBlockingThread$1.run(CCNonBlockingThread.java:180)
                at java.security.AccessController.doPrivileged(Native Method)
                at com.cc.applet.CCNonBlockingThread.processEventData(CCNonBlockingThread.java:178)
                at com.cc.applet.CCNonBlockingThread.run(CCNonBlockingThread.java:139)
Caused by: java.net.SocketException: com.cc.util.controller.email.DummySSLSocketFactory
                at javax.net.ssl.DefaultSSLSocketFactory.createSocket(Unknown Source)
                at com.sun.mail.util.SocketFetcher.startTLS(SocketFetcher.java:249)
                at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:1226)
                ... 12 moreHere is the code:
               Properties props = new Properties();
               props.put("mail.smtp.auth", "true");
               props.put("mail.smtp.host", smtpServer);
               props.put("mail.smtp.starttls.enable","true");
               // the line below is for java 1.5
               java.security.Security.setProperty("ssl.SocketFactory.provider","com.cc.util.controller.email.DummySSLSocketFactory");
               // these are for java 1.4
              props.setProperty("mail.smtps.socketFactory.class","com.cc.util.controller.email.DummySSLSocketFactory");
              props.setProperty("mail.smtps.socketFactory.fallback", "false");
               Session session = Session.getInstance(props, null);
               session.setDebug(true);
               // -- Create a new message --
               Message msg = new MimeMessage(session);
               // -- Set the FROM and TO fields --
               msg.setFrom(new InternetAddress(from));
               msg.setRecipients(Message.RecipientType.TO,InternetAddress.parse(to, false));
               // -- Set the subject and body text --
               msg.setSubject(subject);
               msg.setText(body);
               // -- Set some other header information --
               msg.setHeader("X-Mailer", "FuserDiscoveryProcess");
               msg.setSentDate(new Date());
               // -- Send the message --
               Transport tr = session.getTransport("smtp");
               tr.connect(username, password);
               tr.sendMessage(msg,msg.getAllRecipients());
               tr.close();
               CCLogger.getLogger().log(Level.INFO, "Message sent OK.");

new info it works on 1.5.0_10 but not 1.5.0_06 any ideas?

Dynamically adding JRE for IE, Java Security Warnings, & Next Gen Plugin.

I wrote an portal application to control the environment for a third party application, the portal uses a JRE version that I supply with it, this was to ensure that users are using the same JRE so any issues can be limited to one version of Java. The only piece of the application that I could not specify the JRE version and path was for Internet Explorer. Please keep in mind that I do not control when the system JRE is updated or not, this is pushed to our systems and the latest JRE would be enabled automatically. I wanted to be able to dynamically add and enable the version of the JRE that Microsoft Internet Explorer uses for applets. So I was digging around recently and if I have the next-generation plugin enabled I could programmatically update the deployment.properties file prior to launching Internet Explorer(assuming I have closed all prior instances of IE that were running) to add and enable a version of the JRE which I choose to use. When I launch IE and run an applet I see that it is using the JRE I had dynamically supplied. However everytime I run the applet a Java security warning comes up saying "The application requires an earlier version of Java", I wanted to suppress this message but after research I tried adding 'deployment.security.mixcode=HIDE_RUN' to the deployment.properties, that did not work. I tried disabling the Next Generation Plugin, that worked to suppress the message however internet explorer was no longer using my dynamically supplied JRE for applets in IE, so that was not going to work for my purposes. My questions are:
1. Is there a reliable way(not using ssvagent) to programmatically enable and disable Java's Next Generation Plugin option? (I want to make sure it is enabled when launching third party application from the portal)
2. Is there a programmatic way to suppress the Java Security Warning "The application requires an earlier version of Java", without disabling Java's Next Generation Plugin option?
deployment.properties entries after addition of my jre entry:
#deployment.properties
#Fri Sep 28 14:09:24 PDT 2012
deployment.javapi.lifecycle.exception=true
deployment.trace=true
deployment.javaws.viewer.bounds=323,144,720,360
deployment.javaws.autodownload=NEVER
deployment.version=6.0
deployment.browser.path=C\:\\Program Files (x86)\\Internet Explorer\\iexplore.exe
deployment.security.mixcode=HIDE_RUN
deployment.log=true
deployment.console.startup.mode=SHOW
deployment.capture.mime.types=true
#Java Deployment jre's
#Fri Sep 28 14:09:24 PDT 2012
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.platform=1.6
deployment.javaws.jre.0.osname=Windows
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.0.product=1.6.0_33
deployment.javaws.jre.0.osarch=x86
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=false
deployment.javaws.jre.0.args=
deployment.javaws.jre.1.enabled=true
deployment.javaws.jre.1.registered=true
deployment.javaws.jre.1.osname=Windows
deployment.javaws.jre.1.location=http\\\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.1.osarch=x86
deployment.javaws.jre.1.path=C\:\\Portal\\dist\\java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.1.platform=1.6
deployment.javaws.jre.1.product=1.6.0_29
Note: The reason not to use most recent version of Java is the necessity to test the third party application prior to deployment of a new Java version and since I do not control when a new version of Java is deployed and enabled to our machines, I am required to find an transparent solution. I understand the security issues by doing so, but the time between testing and acceptance of a new Java version for our application is within an acceptable timeframe. On exiting the application, I would restore the JRE settings and restore previous settings, to minimize the exposure of a potential security risk. Also any manual configurations are trying to be avoided as to maintain transparency to the user.

I'm having a similar problem and I think it is related with this.
If, after a Java--->Javascript call, a Javascript--->Java call isn't made soon after the first, it works. But, if the Java--->Javascript call triggers a Javascript--->Java call, any Java--->Javascript call that is made after that doesn't reach Javascript :/
I have a method that handles the Java--->Javascript calls and goes something like this:
System.out.println("Calling Javascript...");
JSObject win = JSObject.getWindow(this);
win.call(jsEventHandler, new Object[] { json.toString() });
System.out.println("Done.");I further found out that, after looking at the Java debug console in the scenario where a Java--->Javascript call triggers a Javascript--->Java call, only after this last method returns is the "Done" message printed, even though the respective Javascript call was already invoked.
Could you explain in more detail the queue based solution you found? Any other ideas?
Regards,
André Tavares.

How do I bundle a jre with an RCP appl on Mac OSX

Hi,
We are making an RCP appl with kepler.
I want to ship the jre's with the appl.
On windows I can just ship a jre dir in the root, no problem.
On the Mac (10.8.4) it does not seem to work, at least not in an obvious way.
I downloaded the latest 1.7 jre (25) for Mac from the oracle website.
I tried the following:
unzip it and put it in a jre dir in the root => not used, falling back to system jre
same and put '-vm' in the ini => error saying 1.6.0_51 is not supported (huh? I do not even have 1.6)
I tried exporting an appl (with bundled jre) from eclipse using the product definition. That works but when I look at the generated appl tree I see a jre dir with another jre dir inside it ??? The inner jre dir seems to be a (partial) duplicate of the outer one.
Ok, sort of at least, now I tried to copy my downloaded jre dir inside itself. That works, but if I remove the contents of one of them it does not work anymore and I do not really want to ship a double jre.
Can anybody shed some light here?
What is the optimal way to bundle a jre with an RCP application on Mac OSX?
Thanks,
Tom

I have done this within our product and have it working. It's tricky because if you're using Maven to build, OS X's JRE symlink's libjvm.dylib - which Java's unzip invariably screws up.
I was only able to get this to work by using Tycho, as the app export within the PDE is just plain broken (and seemingly unmaintained). This bug has been there for quite some time - I don't have any faith in it ever getting fixed, regardless of whatever bugzilla says.
If you're building RCP apps for distribution - you should probably consider using Tycho anyways; admittedly there's a lot of BS that comes with it, but it's the only seemingly straightforward way to build and package an RCP app in a headless manner for continuous integration. Buckminster is supposedly also a solution - but it has less information and support than Tycho - so YMMV.
Anyways back to your problem. Using Tycho with some custom maven magic, I was able to solve this. Essentially I downloaded the JRE from Oracle, and uploaded to our Artifactory so I could reference it using maven coordinates. I unpack that tar.gz package into the OS X distribution directory and place the package under the <your app name>.app/jre. Because of the symlink munging - you have to go and fix that, so remove the existing zero byte libjvm.dylib and relink it using ant exec. Now that you have a good JVM, you need to modify the config.ini to use the right JRE. Unfortunately you can only build this on OS X or Linux - Windows is SOL unless you can find a way to use Cygwin or equivalent. Since I'm doing this outside of Tycho's archiving phase (and theres not apparently way to slip my changes in between), I have to recreate the OS X archive.
Hopefully this helps you solve your problem... I beat my head against the wall trying to fix this for several weeks trying to find a working solution as the error reporting is completely incorrect.
Anyways, good luck!
<profiles>
<profile>
<id>fix-jre-archives</id>
<activation>
<os><family>unix</family></os>
</activation>
<dependencies>
<dependency>
<groupId>com.sri</groupId>
<artifactId>oracle-jre</artifactId>
<version>${distrib.oracle-jre.version}</version>
<classifier>macosx-x64</classifier>
<type>tar.gz</type>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>unpack-mac-jre</id>
<phase>prepare-package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.sri</groupId>
<artifactId>oracle-jre</artifactId>
<version>${distrib.oracle-jre.version}</version>
<classifier>macosx-x64</classifier>
<type>tar.gz</type>
<outputDirectory>${distrib.macosx.x86_64}</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>fix-jre-mac</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<mkdir dir="${distrib.macosx.x86_64}/${distrib.bin.name}.app"/>
<move file="${distrib.macosx.x86_64}/jre${distrib.jre.version}.jre" tofile="${distrib.macosx.x86_64}/${distrib.bin.name}.app/jre"/>
<symlink action="delete" link="${distrib.macosx.x86_64}/${distrib.bin.name}.app/jre/Contents/MacOS/libjli.dylib" />
<symlink link="${distrib.macosx.x86_64}/${distrib.bin.name}.app/jre/Contents/MacOS/libjli.dylib"
resource="../Home/lib/jli/libjli.dylib" overwrite="true"/>
<concat destfile="${distrib.macosx.x86_64}/${distrib.bin.name}.app/Contents/MacOS/${distrib.bin.name}_temp.ini" fixlastline="yes">
<header filtering="no" trimleading="yes">
-vm
../../jre/Contents/Home/lib/server/libjvm.dylib
</header>
<fileset file="${distrib.macosx.x86_64}/${distrib.bin.name}.app/Contents/MacOS/${distrib.bin.name}.ini"/>
</concat>
<move file="${distrib.macosx.x86_64}/${distrib.bin.name}.app/Contents/MacOS/${distrib.bin.name}.ini"
tofile="${distrib.macosx.x86_64}/${distrib.bin.name}.app/Contents/MacOS/${distrib.bin.name}_bak.ini" />
<move file="${distrib.macosx.x86_64}/${distrib.bin.name}.app/Contents/MacOS/${distrib.bin.name}_temp.ini"
tofile="${distrib.macosx.x86_64}/${distrib.bin.name}.app/Contents/MacOS/${distrib.bin.name}.ini" />
</target>
</configuration>
</execution>
<execution>
<id>remove-director-archive-mac</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<delete file="${archive.macosx.x86_64}" />
</target>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.3.1</version>
<executions>
<execution>
<id>manual-archive-mac</id>
<phase>pre-integration-test</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>zip</executable>
<workingDirectory>${distrib.macosx.x86_64}/..</workingDirectory>
<arguments>
<argument>-r</argument>
<argument>-q</argument>
<argument>-dd</argument>
<argument>--symlinks</argument>
<argument>${archive.macosx.x86_64}</argument>
<argument>${distrib.root}</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>

JRE 1.3.1 VS. JRE 1.4.1

Similar Messages

Maybe you are looking for