Community
Participate
Working Groups
I downloaded the Eclipse IDE for Java EE Developers package (based on 3.4.1) from http://www.eclipse.org/downloads/ . When I unpacked the zip file and double-clicked on eclipse.exe I got an error dialog that said: JVM Terminated. Exit Code=-1. The rest of the dialog wasn't useful and I didn't find a log or dump file. I'm using this version of Java (it's the only one installed on this new machine): java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode) I'm running Windows Vista 64-bit SP1. A quick search found bugzilla entries that were similar but not quite the same. However I did see the exact problem reported here: http://www.filsa.net/2008/07/14/eclipse-34-jvm-terminated-exit-code-1/ The workaround is to download the package, unpack it, then download the 64-bit version of the Eclipse SDK (making sure to get the same version as the Java EE Package used), and unpack that on top of the first install. A fix would look like this: build a 64-bit version of all the packages and then auto-detect that the user has 64-bit windows on the download page. Also it should be made clear that the other windows downloads are for 32-bit only (the same way it has 32 and 64-bit Linux versions).
To be clear, you are trying to run a 32 bit Eclipse on a 64 bit vm. The 32 bit Eclipse does run fine on 64 bit vista, it just needs a 32 bit vm. The download page should be made clear that the package requires a 32 bit vm. Sending this over to packaging since producing a 64 bit package would also help clarify things.
As an aside, a better workaround is to install a 32bit vm :) As I understand it, the only advantage of the 64 bit vm is a bigger memory space. Java will run slower in 64 bits, so if you're not using the extra memory, I don't think there is a real reason to go 64.
The question is always the same - why is it not possible to build the packages for platform X (X is something like AIX, Win64, etc.). The answer is really simple: You need someone who is testing the package and is responsible for it in the future. By building the packages for win32, lin32, lin64, maxosx, we provide packages for most developers and users. And in the EPP project, there is nobody that could provide tests on that platform. Willing to join and to provide the necessary level of testing? ;-)
Consider this from a user's perspective. I got a new 64-bit Vista computer. I needed Java so I went to java.sun.com to install it, and the download page asks for a Platform. The choices there are: Linux x64 Solaris SPARC Solaris x64 Solaris x86 Windows Windows x64 I picked Windows x64, which got me the 64-bit JDK. It seems like a natural choice many will make even if they don't understand what they're getting. (In my case I picked it deliberately because I wanted to run other Java programs with >2G heap, but I don't think I'm a typical user.) I installed the Java EE Eclipse package and it didn't work. I was able to figure out why but some people won't be and they'll get a negative out-of-the-box experience, complain on blogs, etc.. Now, if I had gone to www.java.com the flow there does seem to direct everybody to a 32-bit JRE. As a developer I didn't want the JRE, I wanted the JDK. Given the combinations of 32 and 64-bit OS's and JVM's maybe a better fix would be to have two packages: - the 32-bit package that work on all systems/jvms - the 64-bit package that works only with 64-bit os and jvm Or even better, if it's technically possible, one package that detects what you have and runs in either mode. If there was an install program or MSI, that's another option. 64-bit users are only going to get more common. See http://blogs.zdnet.com/Bott/?p=506 which predicts >50% of new PCs sold at retail coming with Vista64 pre-installed soon.
(In reply to comment #2) > As an aside, a better workaround is to install a 32bit vm :) As I understand > it, the only advantage of the 64 bit vm is a bigger memory space. Java will > run slower in 64 bits, so if you're not using the extra memory, I don't think > there is a real reason to go 64. > My 2 cents on this... I think that in late 2008 it does not make any sense anymore to say that "64 bit is useless unless you need more memory"... All the CPUs sold during the latest months (years?) are all 64 bit already, Windows x64 (Vista, in particular) is available for end users and whoever is going to make some serious Java development under Windows is likely to need 4 GB or more of memory... If anyone still doesn't have so much memory, he may need it within some months... and he could already have a 64-bit OS to be ready for that. So, I don't think it's very constructive to keep on saying that 64 bit software should be "an exception"... Mauro.
This has been a valuable report, and discussion. But, since there's no plans to fix things for Ganymede, I'm closing as "won't fix". I think there should be a 64 bit version for Galileo ... and hope some of those desiring that package can get involved to help create, test, etc.
Has this been fixed for Galileo? I don't see any packages for 64 bit Windows anywhere just 64 bit Linux and OSX. I did find the 64 platform download but not a full JEE package.
The discussion has been re-opened for the Helios (3.6) release in bug 293969.
