This page still recommends JRE 6 as prerequisite. When will it recommend JRE 7? With Juno 4.2.2 or with Kepler 4.3?
This is a question for the Planning Council, or perhaps the cross-projects-dev mailing list. wayne March 2013
This article says that Eclipse 3.3 requires a Java 5 Runtime Environment. This conflicts with  which seems to imply that JRE 1.4.2 is still generally acceptable even with Eclipse 3.4, and that if anything it depends on whether you use the EE package or not ("Eclipse IDE for Java EE Developers requires a Java5 JRE"). Which of them is correct? Petef310.fordy.org 15:02, 25 September 2008 (UTC)
Some parts of Eclipse will run on JRE 1.4 or older. Some parts require 5.0 or 6.0. The Java EE bundle, because in addition to Eclipse includes EMF 2.4 (a requirement for the Web Tools project), prereqs 5.0. If you run that bundle with Java 1.4, you will only get partial function because all the plugins that need 5.0 will be disabled. --nickb 15:49, 25 September 2008 (UTC)
Installer can't find JRE
Regarding Indigo c/c++ Windows xp/64 install. JRE is installed but it's not in the expected path. The installer doesn't give any options to change the path. Could we have a PROPER installation explanation? Perhaps a proper installer ...
There are a few different options with regard to the location of the JRE. The FAQ describes how Eclipse finds the JVM. A proper installer would be cool. There have been a few starts on building one. We rely on the developer community to put resources into building it and there just hasn't been a strong drive to do so. --wayne June 2012
Shouldn't an installation under `/opt` be a good point for most Linux distributions for global access on the machine?
# Install OpenJDK in Linux aptitude install openjdk-7-jdk openjdk-7-doc openjdk-7-source openjdk-7-demo # Download Eclipse wget -P /tmp/ http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/luna/SR2/eclipse-jee-luna-SR2-linux-gtk-x86_64.tar.gz # Unpack cd /opt; tar -zxf /tmp/eclipse-jee-luna-SR2-linux-gtk-x86_64.tar.gz; mv eclipse eclipse-luna # Create start script with version name. That so other version still can be used. cd /usr/local/bin cat <<EOF > eclipse-luna #!/bin/sh export UBUNTU_MENUPROXY=0 export ECLIPSE_HOME="/opt/eclipse-luna" \$ECLIPSE_HOME/eclipse "\$@" EOF chmod +x eclipse-luna # ln -s eclipse-luna eclipse # Make desktop icon cat <<EOF > ~/eclipse-luna.desktop [Desktop Entry] Name=Eclipse Luna Type=Application Exec=eclipse-luna Terminal=false Icon=/opt/eclipse-luna/icon.xpm Comment=Integrated Development Environment NoDisplay=false Categories=Development;IDE; Name[en]=Eclipse Luna EOF # Install desktop icon desktop-file-install ~/eclipse-luna.desktop
Article doesn't actually say anything about installing Eclipse itself.
This article doesn't say ANYTHING at all about what one needs to do to install Eclipse itself. The other information is certainly useful and necessary, but really should be under the heading of "Dependencies" or something like that.
Sure it does. It's the part about decompressing the downloaded archive. --wayne June 2012
no more zip problem in Windows?
Current article text says:
- Note that there is a known problem with the built-in decompression utility on all current versions of Windows. We recommend that you use a more robust decompression utility such as the open source 7zip when decompressing an Eclipse download. Some people report success when initially decompressing Eclipse into a root directory (e.g. c:\) and then moving it to a more appropriate home (e.g. c:\Program Files\Eclipse)
but I don't find this to be true. I'm running Windows 8.1 64-bit, and extraction using the unzip util built into Windows yields exactly the same filenames in the same places as using 7-Zip does. --Nobushel (talk) 20:26, 13 January 2015 (EST)
That's good news. We need to confirm that this is generally true. wayne