windows 8.1 64 Bit , Aptana 3.4.2 , Java 64 Bit
Error:
Java :
Must you have 32-bit version of java, or may be you have both version [32-bit 64-bit] of java on same computer.
Make sure you have 32-bit version then must you specify the version that using in Aptana studio to do this :
1-Go to apatana folder and find the AptanaStudio3.ini file
"C:\Users\[YourUser]\AppData\Roaming\Appcelerator\Aptana Studio"
2- Add the java 32-bit version path to AptanaStudio3.ini using notepad
Package arch is 32-bit only for Windows OS. The 32-bit version of the JDK is required regardless of whether it is running on a 32-bit or 64-bit Windows system. You can download here from the official website.
I got the exact same error but I was on Windows 10 64-bit, Aptana 3.6.1, with only 64-bit JDKs.
After I downloaded 32-bit 1.7 JDK, I was able to open and run Aptana just fine.
I didn't need to modify the .ini file as AbuSitta had suggested.
I'll agree it might be misleading to some if you don't take a sharper look and see the "x86, x64" description at the download page.
In Windows OS, Aptana Only runs using Java 32 bit (JRE or JDK)
Am I late to the party ? Just started on ruby yesterday..and this was the recommended IDE in 3 of the 4 tutorials i saw..Spent the whole day trying to configure this.
Aptana Studio needs 32 bit jdk to be installed even on a 64 bit processor.. The "compatibility" suggested is a bit misleading..I just had to install the 32 bit jdk.. Did not modify the .ini file as #Osama Abusitta said. Just restarted the pc post installation for the effect to take place.
I got the Same Error. just install Java jdk.1.8 x86 (32bit) Version.
modify the .ini file
C:\Users\YOUR_USER\AppData\Roaming\Appcelerator\Aptana Studio\AptanaStudio3.ini
-startup
plugins/org.eclipse.equinox.launcher_1.4.0.v20161219-1356.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.551.v20171108-1834
--launcher.defaultAction
openFile
-vm
C:\Program Files (x86)\Java\jdk1.8.0_202\bin\javaw.exe
-name
Aptana Studio 3
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.8
-Xms256m
-Xmx1024m
--add-modules=ALL-SYSTEM
-Declipse.p2.unsignedPolicy=allow
-Declipse.log.size.max=10000
-Declipse.log.backup.max=5
-Dfile.encoding=UTF-8
-Djava.awt.headless=true
Related
Worldwind is giving an error about missing dependencies. The executable works on 8/10 computers (intel) all with the same software & versions (Windows 7 w/ Jre8), same graphics cards/drivers (recently new).
On the computers where Worldwind doesn't work, the error was UnsatisfiedLinkError -"gluegen-rt.dll: Can't load AMD 64-bit .dd on a IA 32-bit platform"
To fix this, I downloaded the JOGL dll files for Intel i856, removed the AMD files and the program gives me this error [1]: https://i.stack.imgur.com/mRYRU.png
Any suggestions/comments are greatly appreciated.
Turns out using the jogamp-fat.jar the computer was looking at the 32-bit version of java. Once I installed Java 64-bit version and changed the JAVA_HOME it worked. Thanks!
My JavaFX Application is installed correctly in Windows 8 (64 bit) but refuses to run !
I use the JavaFX native packager to produce native install bundles for Windows (from an Eclipse / Ant script).
I create my Windows bundle from a 64-bit Windows 7 build machine - JDK used
: 8u66 b02 early access - 64-bit Windows.
Unfortunately there is no logs generated by Windows ! So it's difficult to know the cause of the crash.
For information this is the list of DLL installed :
MSVCP120.dll
MSVCR100.dll
MSVCR120.dll
My problem is similar to this issue (Java Bug system) : https://bugs.openjdk.java.net/browse/JDK-8131321
But this bug normally was fixed !
Any ideas ?
My development team recently was forced over to a remote development environment where we do not have full access to the servers. Before the change over we had a JAR that was running fine on Java 1.7 x64 along with JRE 7. When we moved over to the new server our JAR was running alright, but then one of the server admins "updated" our Java to an older version and uninstalled the one we were using. Don't ask me why, I don't know. I re-installed Java 1.7 and uninstalled 1.6 along with the JREs.
The following problem occurs at runtime, there are no build errors:
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I've run the same JAR on my laptop with no issues. Both the server and my laptop have JDK 1.7 and JRE 7 in the respective %HOME% variables and system PATH. I've even reinstalled JRE 6 and placed it later in the system environment PATH variables with the same result.
I have also changed the registry back to look at 1.6 and it results in the following, which I looked up and it appears to be from having multiple Javas installed (leading back to my original problem):
Exception in thread "main" java.lang.UnsupportedClassVersionError: ... :
Unsupported major.minor version 51.0
I would appreciate any insight you all have as I have been looking over various forums but nothing seems to have exactly my problem. Also, this has happen on another server we are using as well. Thanks!
Update: No luck with recompiling the JAR to either 1.6 or 1.7 and matching the JDK. Also, why in the world would a newer version of Java break an older compiled version?
This happens when you somehow confused java itself. You are trying to run a java 6 VM where it found a JRE 7. It might show this problem even if you type in the command line just java or java -version in a misconfigured environment. The JAR is not the problem, except in the very unlikely case where the code in JAR is looking in the Windows Registry for that (which probably is not your case).
In my case, I had the java.exe, javaw.exe and javaws.exe from Java 6 in the Windows/System32 folder (don't know how it got to be there). The rest of the JDK and JRE where found in the PATH inside C:\Java\jdk_1.7.0\bin. Oops!
Just had the similar error when installing java 8 (jdk & jre) on a system already running Java 7.
Error: Registry key 'Software\JavaSoft\Java Runtime
Environment'\CurrentVersion' has value '1.8', but '1.7' is required.
Error: could not find java.dll Error: Could not find Java SE Runtime Environment.
My environment was set up correctly (Path & java_home correctly defined), but the problem arises from the way pre-8 Java installers worked, which is that they used to copy the three executables (java.exe, javaw.exe & javaws.exe) to the Windows system directory. These remain unless overwritten by a new pre-8 installation.
However the Java 8 installer instead creates symbolic links in a new directory, C:\ProgramData\Oracle\Java\javapath, pointing to the actual JRE 8 location.
This means that you'll actually run the old 7 exes but use the new 8 DLLs.
So, the solution is simply to delete the 3 Java exes, as above, from the windows system directory.
If you are running 32-bit Java on a 64-bit Windows, the exes would be in Windows\SysWOW64, otherwise in Windows\System32.
I've deleted java files at windows/system32 and I also have removed c:\ProgramData\Oracle\Java\javapath from the PATH variable, because there was 3 symlinks to java 1.8 files.
I had JDK 1.7 in the %JAVA_HOME% variable and java1.7/bin in the PATH.
PS1: My problem was between Java 1.7 and Java 1.8.
PS2: I can't add this as a comment to Victor's answer because I haven't enough points.
In the START menu type "regedit" to open the Registry editor
Go to "HKEY_LOCAL_MACHINE" on the left-hand side registry explorer/tree menu
Click "SOFTWARE" within the "HKEY_LOCAL_MACHINE" registries
Click "JavaSoft" within the "SOFTWARE" registries
Click "Java Runtime Environment" within the "JavaSoft" list of registries here you can see different versions of installed java
Click "Java Runtime Environment"- On right hand side you will get 4-5 rows . Please select "CurrentVersion" and right Click( select modify option) Change version to "1.7"
Now the magic has been completed
I don't know if anyone is still following this thread, but I recently had this issue when I tried to launch ActiveMQ 5.10 as a Windows service.
I didn't have a JAVA_HOME path set.
I had Java 6 and Java 7 installed, but the default version was v7. (ie if I opened a command window and types "java -version").
This is where the clue was - "java -version" returned "Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)" but I was had installed the Win32 service...
It turns out that if you use the Win32 wrapper on a 64-bit machine it somehow decides to use a different version of Java...
So my fix was to uninstall the 32-bit version of the wrapper and install the 64-bit version.
aversion on my machine; just habit I guess... But luckily I resolved the issue eventually...
For my Win7
Paradox was in being java.exe and javaw.exe in System32 folder.
Opening that folder I couldn't see them but using search in Start menu I get links to those files, removed them. Next searsh gave me links to files from JAVA_HOME
magic )
Change to directory with correct java.exe i.e. go to the required JDK version java.exe
cd C:/Program Files/Java/jdk1.7.0_25/bin
Run the java.exe from this directory, it has precedence over registry and $PATH settings.
java -jar C:/installed/selenium-server-standalone-2.53.0.jar
I solved this problem by uninstalling Java 1.8
The jar was compiled to be 1.6 compliant. That is why you get this error. Two resolutions:
1) Use Java 1.6
OR
2) Recompile the jar to be compliant for your environment 1.7
Using regedit, remove the entries corresponding to java 7. It will work.
I have a system running 64bit windows 7. I'm doing a project using JMF, which I found works best (or only) with 32 bit jdk. I'm using a 32bit eclipse. I also have a 64bit JDK installed. right now I have set classpath (JAVA_HOME and Path) for the 32bit JDK.
The problem is it becomes hectic to switch between the 64bit and 32 bit JDK(i have to change classpaths everytime). Is there any easier way to do that?
You can have multiple JREs registered with Eclipse, and associate a project or run configuration with a specific JRE. These are different from the JRE you use to run Eclipse in.
Eclipse doesn't need to depend on JAVA_HOME or PATH. You can specify the JVM to be used to run Eclipse in the eclipse.ini file, and specify the path(s) to the target JVM(s) via the Eclipse preferences.
If you have to run both 32 and 64 bit Java from the command line, you should invest some time in writing shell scripts, aliases, etc.
You could write a script (to be executed using ".") that will switch the settings of PATH and JAVA_HOME.
I prefer the approach of writing simple wrapper scripts or aliases to automate the build or run steps for the software you are developing. You can embed local overrides of PATH and JAVA_HOME in these scripts.
I would suggest just keep one JDK installed on your machine.
If you are working with JMF and Eclipse 32 bit then uninstall 64bit JDK
As per Oracle.
To run 64 bit eclipse without change environment variable
Simply copy 64bit jre to your eclipse(64 bit) root folder and rename it as jre.
We have a project that compiles to a 32-bit COM DLL and to a 64-bit COM DLL (the same one from my earlier question). When I register both on my Windows 7 machine, both register successfully. When I register both on a Windows Server 2003 machine, both register successfully.
But when I try to register the DLLs on a Windows Server 2008 R2 standard SP1 machine, the 64-bit DLL registers successfully, but the 32-bit DLL fails with the message (sic):
The module ""%1"" may not compatible with the version of Windows that you're running.
Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe.
I don't think a 32-bit DLL can be compatible with WS2003 and Win7 but not WS2008. That makes no sense.
What might be happening?
The version of Regsvr32.exe must match the 32-/64-bitness of the dll you're trying to register. The 64-bit regsvr32 cannot load a 32-bit dll, and vice versa.
You may need explicitly call the 32-bit version of regsrv32 located in %systemroot%\SysWoW64\regsvr32.exe.
From http://support.microsoft.com/kb/249873
Regsvr32.exe is included with Microsoft Internet Explorer 3.0 or later versions, Windows 95 OEM Service Release 2 (OSR2) or later versions, and Windows NT 4.0 Service Pack 5 (SP5) or later versions. Regsvr32.exe is installed in the System (Windows Me/Windows 98/Windows 95) or System32 (Windows NT/Windows XP/Windows Vista/Windows 7) folder.
Note On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
Regsvr32.exe usage
RegSvr32.exe has the following command-line options:
Regsvr32 [/u] [/n] [/i[:cmdline]] dllname
/u - Unregister server
/i - Call DllInstall passing it an optional [cmdline]; when used with /u calls dll uninstall
/n - do not call DllRegisterServer; this option must be used with /i
/s – Silent; display no message boxes (added with Windows XP and Windows Vista)
When you use Regsvr32.exe, it attempts to load the component and call its DLLSelfRegister function. If this attempt is successful, Regsvr32.exe displays a dialog box that indicates success. If the attempt is unsuccessful, Regsvr32.exe returns an error message. This may include a Win32 error code. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
193625 WinInet error codes (12001 through 12156)
This isn't likely to be the problem in your case, but might be useful for others who find this question by searching on the same error message:
I had a similar problem: a DLL that wouldn't register with either the 32-bit or 64-bit version of RegSvr32. I loaded the DLL the Dependency Walker (depends.exe, http://www.dependencywalker.com/) and got a much more useful message:
Error: At least one file was not a 32-bit or 64-bit Windows module.
Scanning the CPU column in the Module List identified the offending module. (In my case, it said "No DOS or PE signature found. This file is not a valid 32-bit or 64-bit Windows module.")
Moral: The Dependency Walker might give you a more useful error message than RegSvr32.exe.
I got it registered by moving the dll to the c:\windows\syswow64\ directory (it wouldn't work in the system32 directory) and then explicitly calling syswow64\regsvr32, eg
c:\windows\syswow64\regsvr32 yourdll.dll
btw it wouldn't work when calling c:\windows\syswow64\regsvr32 c:\windows\syswow64\yourdll.dll
Use Process Monitor from SysInternals.
1. Filter by "Process Name" = regsvr32.exe.
2. Try to register your DLL file from the correct version of regsvr32.exe (the 32-bit version is in the SysWow64 folder)
3. Process Monitor will trace EVERYTHING that is happening on your computer.
4. First start your analysis by eliminating the registry events (for now):
5. You may be able to see which DLL file is found and not found.
Here a (very) partial screenshot of regsvr32.exe of Threed32.ocx where we can see some of the required DLL files:
6. Your work is just starting. From now.
I have the same problem, but I resolve it with commands
CD \windows\syswow64
regsvr32 c:\filename. dll
Running the command prompt as administrator fixed my issue.