I have just watched the bug report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6972329 so I want to ask... Is there a JDK upgraded version which handles the problem? Because if I develop an app with 32-bit JDK 6 will it work on 64-bit linux?
I have compiled my project with jdk 1.6.0_05 so I am not sure will it work for 32 or 64 bit linux ... won't it be the user.home as '?'
Thanks
The bug has absolutely nothing to do with the JDK used to compile Java code - Java bytecode is completely platform independant. The bug only occurs when you run a Java app on a 32bit JVM on a 64bit Linux, and even then it seems to depend on a specific (and possibly faulty) LDAP configuration.
Related
RHEL 6.6 has openJDK java version "1.7.0_65" and RHEL 6.9 has openJDK java version "1.7.0_131".
What is the difference between openJDK java version "1.7.0_65" and openJDK java version "1.7.0_131".
Does it has any impact on the product? Which was working fine previously with openJDK java version "1.7.0_65".
How it makes difference keeping only openJDK java version "1.7.0_65" in linux server RHEL 6.9 than keeping openJDK java version "1.7.0_131" in linux server RHEL 6.9
Kindly someone clarify my query.
Thanks in advance.
1.7.0_65 is very old jdk. That means it is full of known, security bugs - see https://www.oracle.com/technetwork/topics/security/alerts-086861.html.
Every 1/4year, oracle releases bunch of fixes for openjdk. Red Hat engineers backport them for you to openjdk7. So jdk gets updated aprox 4x per year in rhel 6.
Big deal is given in RedHat to keep rhel X compatible during its lifecycle, and java is no exception. So the update from 1.7.0_65 to 1.7.0_131 (guessing with 6.6->6.9 update) should be perfectly smooth. In unlike case of accident, it is case to red hat bugzilla xor custommer portal and rh's OpenJDK team will do its best to fix it.
Long story short, is is very bad idea to have such old jdk on your system.
RHEL 6.6, as initially released, has java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el6_5. This version is based on OpenJDK 7u65 and IcedTea 2.5.1, released 2014-07-16. As such, it is over two and a half years old.
RHEL 6.9 has java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el6_8 which was released on 2017-02-14. Between those two versions, there have been numerous bug fixes and several security updates.
Oracle release Java security updates on a quarterly basis and we at Red Hat apply those to our packages. Since taking over leadership of OpenJDK 7 after 7u80, we also create the backports for that version, using the patches from OpenJDK 8.
Upgrading to the newer version should be low risk, as each new build is testing against the Java 7 compatibility kit provided by Oracle. There is more of a risk in continuing to use a version which is prone to several known security exploits.
Moreover, if you raise a bug, one of the first things we're likely to ask you to do is try the latest version, and any fix for such a bug would go to the new version, not the unsupported 1.7.0_65.
There should also be a new release based on OpenJDK 7u141 coming in the next few weeks. That will contain a further collection of security updates and bug fixes.
Full details of each version are available on my release blog.
I downloaded and installed the go1.1.2.windows-amd64.msi from the Go distribution page and set it up on eclipse with the goclipse plugin.
The baffling thing is that in the goclipse settings, the GOARCH settings don't seem to matter. I can start a new project with the GOARCH settings set to arm, 386 or amd64 and the project will still compile and run just fine.
Is there a setting i'm supposed to conform to or does the GOARCH setting not matter at all?
Additionally, are the Go distributions with the suffix amd64 supposed to be for 64bit AMD chips and not intel ones? (the naming convention was a little confusing)
My Current Setup:
Eclipse Keplar 64bit
Goclipse 0.7.6
go version go1.1.2 windows/amd64
running on windows 7 64-bit on a Intel i7-3630QM
Don't know about goclipse, but as to suffix on windows
GOARCH=386 will generate 32 bit OS exe
and
GOARCH=amd64 will make 64 bit exe.
Go generated programs will run on any modern CPU that your Windows runs (excluding ARM).
Alex
I'm trying to run Eclipse 4.2 (latest from website: eclipse-SDK-4.2-macosx-cocoa-x86_64) on Mac OS X 10.8 (Mountain Lion).
I have Java 7 installed, but I keep getting prompted to install Java 6. When I choose to forgo the install by clicking "Not Now", Eclipse exits.
$ java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b06)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
$ whereis java
/usr/bin/java
Any ideas on how to get Eclipse to work with the latest version of Java? README is lacking any useful information (and even claims Eclipse was tested with Java 7 on some platforms).
UPDATE:
Running sudo /Applications/.Eclipse/Eclipse.app/Contents/MacOS/eclipse works fine. After running under sudo and then switching back to lowly me with /Applications/.Eclipse/Eclipse.app/Contents/MacOS/eclipse results in a lock file error (permission denied).
It appears I have two problems:
Running through icon click results in "Need Java 6"
Running from command line results in "Permission Denied"
UPDATE: It appears to be more junk from Cupertino:
Apple Radar: 12082976
Here's the text that Apple wants to hide from the world:
I purchased a new Mac Book Pro. I immediately upgraded to Mountain Lion. I installed Java 7 from Sun [Oracle]:
$ java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b06)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
$ whereis java
/usr/bin/java
$ /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home
When I attempt to run the Java Preferences (in /Applications/Utilities) and Eclipse, I get prompted to install Java (see attachment).
This outdated article was no help (adding environment.plist): https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html. I thought the problem might be $JAVA_HOME was not set, but I was wrong.
I think I got more useful information from Stack Overflow rather than the vendor (Apple), but its still not solved. https://apple.stackexchange.com/questions/58203/mountain-lion-with-java-7-only and https://apple.stackexchange.com/questions/57986/multiple-java-versions-support-on-os-x-and-java-home-location.
Please fix this. I spends thousands on Apple hardware and hundreds on Apple software, and this sort of thing is not acceptable. I have personally wasted hours on this issue, as have others. How can the Apple QA department miss another gapping hole?
From here.
JDK 7 will be installed under /Library/Java/JavaVirtualMachines/1.7.0.jdk, JDK 6 under /System/Library/Java/JavaVirtualMachines.
To trick OS X to accept Java 7 instead of proposing to install Java 6 a simple symlink is enough:
sudo mkdir /System/Library/Java/JavaVirtualMachines
sudo su ln -s /Library/Java/JavaVirtualMachines/1.7.0.jdk /System/Library/Java/JavaVirtualMachines/1.6.0.jdk
Most Java Programms will run with this little hack without the need to install Java 6.
Note that the OP in the above question specifically talks about Eclipse not working with Java 7.
Also this might be worthwhile read.
I'm rather embarrassed but one of my students helped me solve this issue.
If you have Java 7 installed then you should be using the 64 bit version of Eclipse. I had downloaded the 32 bit version and it was asking me to install Java 6 when I had version 7 installed. Downloaded the 64bit version and it works like a dream. I run Mac os 10.8
Installing this update from apple fixed it for me:
http://support.apple.com/kb/DL1572
Note that's the update that's trying to install automatically.
Can you imagine that? You have to install a JDK 1.6 to get eclipse ran properly, even if you already have jdk 1.7 installed, and set the JAVA_HOME properly.
To resolve your issue, you just need to download the jdk1.6 from http://support.apple.com/kb/DL1572?viewlocale=en_US, and install it, later you will be able to run eclipse, and you can set the JAVA_HOME to JDK1.7, and you will be able to find the JDK1.7 from eclipse "Preferences".
The MAC OS offers the Java Preferences tool under Applications.
If you don't have this tool you can edit the eclipse.ini and manually specify the JVM that you want to use.
Of course remember that Java 7 is the only Java official release for MAC and is probably not the best for developing applications. I would go for the 1.6 release but you are forced with this one due to OS restrictions if you want to stick with the standard.
This might be a dumb/naive question, and if it is please excuse me :)
I have a brand new machine with the following specs:
Inter Core i7 2600#3.4GHz
RAM 8 GB
Windows 7
This machine has a 64 bits architecture.
On my previous machine, I used to install 32 bits versions of Eclipse and run it using a 32 bits JRE, and my current Eclipse setup works perfectly on the new machine.
I tried to install a 64bits version of Eclipse, and run it with a 64 bits JRE, and I am wondering if there are any compelling reasons to switch to this kind of setup or stick to my existing install. I guess that I would have to reinstall all the plugins, and maybe find that some of them are not compatible with the 64 bits version of Eclipse.
So far, the 64 bits version seems to need quite some more RAM than the 32 bits version, which is something that I expected, but nothing seems to have improved.
Thanks for your advice!
In general I use 64-bit Eclipse without problem, but there can be issues around plug-ins such as:
Adobe Flash Builder only works with 32-bit
The Subversion plug-in Subclipse needs a native 64-bit version of Subversion installed separately
There may be more but those are the ones I've encountered in the past.
Moving to 64-bit gives you access to more addressable memory but it won't speed anything up, in fact it might reduce performance in some cases (but nothing I see as significant to what I do).
Well the only thing that will improve is that you are able to use the advantages of 64bit. Other then that I'm not aware of any improvement.
For example what's better in 64bit is that if you have a very large project set you would be able to handle it more comfortably. For more information on 64-bit please look here
If you want to be on the edge of technology your choice would of course be the 64bit setup.
About the ram, this is expected because some of the Datatyps now use 64bit and are therefore larger to store in memory.
For most plugins you will get a 64bit version or alternative and so far for what I've used it it always worked.
This may be a silly question but should I use the 32 bit or 64 bit version of Eclipse on my Mac?
I'm fully up to date with Snow Leopard and all patches and I have a pretty recent iMac (30", Dual Core, 3GB)
I thought that Java on Snow Leopard was now 64 bit only so can't understand why there is a 32bit download. Is it just the Eclipse download page that is showing 32 bit for older versions of OSX?
You're probably better off with the 64-bit edition. Nearly all the system software is 64-bit in Snow Leopard, and if you only run 64-bit apps, you don't pay the cost of having to load the 32-bit runtimes (which can consume quite a lot of memory). It may also benefit from the 64-bit memory model, though I'm not sure how well the JVM takes advantage of that yet. I expect the 32-bit version is provided for Leopard (and earlier) compatability.
I would use 64bit Eclipse.
safe bit is 32-bit :)