I have two different versions of eclipse that both quit working on me, I am using windows 7 home premium, the versions of eclipse that I have are Eclipse Luna 4.4 and Eclipse Juno. I have done the following things to correct the error but I am not getting a crash report or anything. In the following order I have tried:
Restarting my computer,
Deleting eclipse and reinstalling,
From command running
Eclipse.exe -clean
Eclipse.exe -clean -clearPersistedState
Eclipse.exe -debug
I have also checked my JAVA_HOME environment variable which is properly set, and the PATH environment
Variable which is also properly set. Still not sure what is going on.
:::EDIT:::
Ok I did Find a report on my windows compatibility checker saying that the application
is incompatible with windows and the repair the issue section failed to repair it.
I do know that two days ago I was working in the eclipse environment without a problem.
When I got home yesterday my machine showed that there had been new updates installed. I
didn't have any issues until yesterday. So I guess my next question is how do I find what
made the application incompatible with my machine, and if it was the updates how do I reverse
them so that I can get my IDE back, I could switch to Netbeans But I prefer to not have to do
so It just doesn't make any sense to do so if I could somehow manage to get eclipse working
again.
all give me the same result, a quick flicker of what I imagine is the Eclipse splash screen and that is it, so my question is where might I find a crash or debug report (if one is generated by eclipse) other wise does any on have any idea what may be happening.
THANKS..
Running Eclipse
After installing the Eclipse SDK in a directory, you can start the Workbench by running the Eclipse executable included with the release (you also need at least a JDK6 or JRE 6, not included with the Eclipse SDK). On Windows, the executable file is called eclipse.exe, and is located in the eclipse sub-directory of the install. If installed at c:\eclipse-SDK-4.4-win32, the executable is c:\eclipse-SDK-4.4-win32\eclipse\eclipse.exe. Note: Set-up on most other operating environments is analogous. Special instructions for Mac OS X are listed below.
Allocating enough memory and solving OutOfMemoryErrors
By default, Eclipse will allocate up to 384 megabytes of Java heap memory. This should be ample for all typical development tasks. However, depending on the JRE that you are running, the number of additional plug-ins you are using, and the number of files you will be working with, you could conceivably have to increase this amount. Eclipse allows you to pass arguments directly to the Java VM using the -vmargs command line argument, which must follow all other Eclipse specific arguments. Thus, to increase the available heap memory, you would typically use:
eclipse -vmargs -Xmx
with the value set to greater than "384M" (384 megabytes -- the default).
When using an Oracle JRE, you may also need to increase the size of the permanent generation memory. The default maximum is 64 megabytes, but more may be needed depending on your plug-in configuration and use. When the VM runs out of permanent generation memory, it may crash or hang during class loading. The maximum permanent generation size is increased using the -XX:MaxPermSize= argument:
eclipse -vmargs -XX:MaxPermSize=
This argument may not be available for all VM versions and platforms; consult your VM documentation for more details.
Note that setting memory sizes to be larger than the amount of available physical memory on your machine will cause Java to "thrash" as it copies objects back and forth to virtual memory, which will severely degrade your performance.
Selecting a workspace
When the Workbench is launched, the first thing you see is a dialog that allows you to select where the workspace will be located. The workspace is the directory where your work will be stored. If you do not specify otherwise, Eclipse creates the workspace in your user directory. This workspace directory is used as the default content area for your projects as well as for holding any required metadata. For shared or multi-workspace installs you must explicitly specify the location for your workspace using the dialog (or via the "-data" command line argument).
Specifying the Java virtual machine
Here is a typical Eclipse command line:
eclipse -vm c:\jdk7u45\jre\bin\javaw
Tip: It's generally a good idea to explicitly specify which Java VM to use when running Eclipse. This is achieved with the "-vm" command line argument as illustrated above. If you don't use "-vm", Eclipse will look on the O/S path. When you install other Java-based products, they may change your path and could result in a different Java VM being used when you next launch Eclipse.
To create a Windows shortcut to an installed Eclipse:
Navigate to eclipse.exe in Windows Explorer and use Create Shortcut on the content menu.
Select the shortcut and edit its Properties. In the Target: field append the command line arguments.
Opening this shortcut launches Eclipse. (You can drag the shortcut to the Windows Desktop if you want to keep it in easy reach.)
Mac OS X
On Mac OS X, you start Eclipse by double clicking the Eclipse application. If you need to pass arguments to Eclipse, you'll have to edit the eclipse.ini file inside the Eclipse application bundle: select the Eclipse application bundle icon while holding down the Control Key. This will present you with a popup menu. Select "Show Package Contents" in the popup menu. Locate eclipse.ini file in the Contents/MacOS sub-folder and open it with your favorite text editor to edit the command line options.
On MacOS X you can only launch a UI program more than once if you have separate copies of the program on disk. The reason for this behavior is that every UI application on Mac can open multiple documents, so typically there is no need to open a program twice. Since Eclipse cannot open more than one workspace, this means you have to make a copy of the Eclipse install if you want to open more then one workspace at the same time (bug 139319).
If you need to launch Eclipse from the command line, you can use the symbolic link "eclipse" in the top-level eclipse folder. It refers to the eclipse executable inside the application bundle and takes the same arguments as "eclipse.exe" on other platforms.
On Mac OS X 10.4 and later, you may notice a slow down when working with significant numbers of resources if you allow Spotlight to index your workspace. To prevent this, start System Preferences, select the Spotlight icon, then the Privacy tab, then click the Add button ("+") and find your workspace directory in the dialog that appears.
Shared Install
The startup speed of a shared install can be improved if proper cache information is stored in the shared install area. To achieve this, after unzipping Eclipse distribution, run Eclipse once with the "-initialize" option from an account that has a write access to the install directory.
Related
I want to increase the initial RAM allocated to run a particular jar that needs it. However, passing the parameter "-xms1g" to the system JRE seems to prevent the launch of a JNLP file that I need to submit credentials for access to the U.S. Patent Office Private PAIR website:
https://ppair.uspto.gov/TruePassWebStart/AuthenticationChooser.html > "Authenticate with Java Web Start (new method)".
When the JNLP launches properly, it opens a GUI that prompts you to entire the filename and path of a certificate in one field, and a password in another field, and then it automatically closes and brings up the private PAIR website in your web browser, if your credentials are valid. You don't have to have a certificate or password to duplicate or test for my issue, as my problem is not getting the prompt to pop up.
For consistent testing and development of my jar, I want to run it on the latest JRE release, which I have to assume other users of my jar will be running. I believe I may also need to use the latest JRE release when launching the JNLP to access the USPTO, for security reasons. Maybe someone who understands cyber-security better than I do could tell me that JRE version doesn't matter when I am launching a JNLP file instead of running an applet through the Java browser plugin (the so-called "old method"), the latter plugin being what Google Chrome stopped supporting, but I don't want to assume that.
So ideally I would like to have two installed instances of the same (latest) JRE version and pass the -xms1g parameter only to the instance I use to run my jar, not to the (system) instance that launches the JNLP. Is this possible? When I tried executing the JRE installer twice, selecting different folders, I found that the second installation had deleted everything from the first folder.
So ideally I would like to have two installed instances of the same (latest) JRE version and pass the -xms1g parameter only to the instance I use to run my jar, not to the (system) instance that launches the JNLP. Is this possible? When I tried executing the JRE installer twice, selecting different folders, I found that the second installation had deleted everything from the first folder.
You do not need two installations of the same JRE to run different java processes with different options. Ensuring that is the purpose of providing them as command-line options. You can choose the non-default options you want when you launch the JVM, whether by configuring them in a shortcut, recording them in a launch script (taking the form of a batch file on Windows), or typing them manually on the command line.
I'm trying to create a portable environment (USB Flash/Disk) that can be copied from one device to another - and work "out of the box" on a Mac/OSX (10.10.x environment) specifically. My purpose for this, is I'm teaching a "Portable Programming" class next semester, and I want to be able to just copy (or give the student a .zip file), have them expand it on a specifically named volume, and the environment works. This includes the SDK version(s), AVDs, etc. I've got everything apparently working (so far), but have a problem with the AVDs.
This is a new install, using latest Eclipse, etc.
I'd hoped to find these directories, etc. within an XML/INI file, and use an editor or sed to change the strings, but can't seem to find the directory names of anything I've needed to change so far within an XML/INI file within the unzipped Android directory - but don't see them.
I do see a reference within Preferences->Android->Build "Default debug keystore" that references ~./android - but it is not editable. There IS a "custom" debug keystore setting on the same dialog page, but changing it does not seem to have an effect on the AVDs and their location. So far, that's the ONLY reference I've found for my home directory. I've looked at the Eclipse CLI at eclipse.org, but don't seem to see anything relating to this issue (at least not anything that's ringing a bell with me).
So - how can I change my default "home" directory (without boogering up the environment, etc.) for Eclipse/Android, so my AVDs (and whatever else I HAVEN'T run into yet), can be installed and used/run from the USB drive/stick?
Please - I DO NOT WANT links to other "portable" packages, as I'm not sure what's actually been altered in them (and probably not current, and an update is likely to hose everything anyway), and don't want to pass along anything to students. I'm downloading official packages from official locations, and want to keep it that way. So I'm only looking for things that can be fixed/edited within an officially installed environment to get the effect I'm looking for. Thanks!
Found this at Launch mac eclipse with environment variables set
There is an alternate solution which involves replacing the executable that is run by MacOS X when the user launches the Eclipse application with a shell wrapper that sets up the environment.
Create an empty text file called "eclipse.sh" in the Eclipse application bundle directory /Applications/eclipse/Eclipse.app/Contents/MacOS.
Open the eclipse.sh in a text editor an enter the following contents:
#!/bin/sh
export ENV_VAR1=value
export ENV_VAR2=value
logger "`dirname \"$0\"`/eclipse"
exec "`dirname \"$0\"`/eclipse" $#
In the example ENV_VAR1 and ENV_VAR2 are the environment variables being set up. These variables will be visible to processes launched from within Eclipse. The logger command will just log the path of the eclipse executable to the system.log as a debugging aid.
In the Terminal set the executable flag of the shell script eclipse.sh, i.e.:
chmod +x /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.sh
Open the Eclipse.app Info.plist and change the value for the key CFBundleExecutable from eclipse to eclipse.sh.
MacOS X does not automatically detect that the Eclipse.app's Info.plist has changed. Therefore you need to force update the LaunchService database in the Terminal by using the lsregister command:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -v -f /Applications/eclipse/Eclipse.app
The next time you launch Eclipse.app from the Dock or from the Finder the environment variables should be set.
It took me a while to research, as that info was from Sep. '09, which was back in Snow Leopard (OSX 10.6) days. I'm now running 10.10, and while some things don't change - a LOT has changed, so it took a while to research the above approach and make sure it wasn't going to do some potential damage to the installation. A LOT of under-the-cover stuff has changed in those 4 versions, and I wasn't willing to just take off with it. I've also not found a good explanation of exactly what ANDROID_SDK_HOME actually controls - although this above approach seems to work - so far.
I am running Eclipse on two MAC OS X (10.9.4) machines. Both systems are running Kepler and both configurations should be identical. But when I launch the application under development on one system, I do get the error message
Unable to save configuration file ".../.plugins/org.eclipse.pde.core/.../org.eclipse.update/platform.xml.tmp"
while the other system is behaving fine. It has nothing to do with access rights or disk space. The TMP file has a size of 0 bytes. If I remove any files or directories, they will be recreated except the platform.xml, platform.xml.tmp resp.
The behavior is reproduceable with the Luna release. But I think the error message is misleading. It suggests insuffient access rights or disk space. But it must be caused by a configuration error.
Does any one have an idea where to look?
You have to close your Eclipse IDE and then delete this folder:
".../.plugins/org.eclipse.pde.core/<the_name_of_the_configuration_you_launch>/"
Start your Eclipse again and you're good to go.
Somehow PDE-build and the launcher conflicts. I don't know why exactly, but you can fix it with this delete.
Try to run Eclipse as an Administrator. In Windows, Right click the exe file and then select "Run as Administrator". If it starts successfully, check your Eclipse and Workspace folders' Security Permissions.
I installed Netbeans on OSX Mountain Lion running JDK 7. Everything was working fine. Then my machine for no reason crashed. After this I could no longer open Netbeans anymore.
If I try to start Netbeans from the commandline:
/Applications/NetBeans/NetBeans 7.2.app/Contents/MacOS/netbeans
Then it works fine. From there I can select Netbeans > About and confirm that my userdir and cachedir is:
User directory: /Users/<user>/Library/Application Support/NetBeans/7.2
Cache directory: /Users/<user>/Library/Caches/NetBeans/7.2
So, I deleted these directories and tried again, but alas, I can only start netbeans via the commandline.
Ideas appreciated...
Sounds to me like this is not a NetBeans problem at all, rather a problem with the bundle, such that OS X is not launching the app as it should.
To verify, I'd try opening NetBeans through Finder from the command line:
open -a "NetBeans 7.2.app"
This command will ask the system launcher to open the application as if you had clicked on the icon. In your case, it probably won't open. If this is true, then you know it's not something in your terminal environment that's allowing NetBeans to launch.
The next step that I would take would be to look at the package contents: examine /Applications/NetBeans/NetBeans 7.2.app/Contents/Info.plist for anything that seems amiss - this file is the information store that OS X looks for to see how to launch the package, what its icon is, etc... - in particular, I think you should look at the CFBundleExecutable value to see what command is used to launch the app. If it's not netbeans, you've found a big hint on what might be amiss: bundles are set up so that launchers should run bundle_dir.app/Contents/{platform}/{CFBundleExecutable_value}. Looking at CFBundleExecutable should show you if there's some other script used to launch the app than just running netbeans.
From this point, you'll have to do more digging, but hopefully this is enough information for you to get started tracking down how apps are launched from the OS X launcher. For more info and a better reference, check out this link, which is Apple's documentation for keys in Info.plist.
Finally, you should note that the launch information for all apps are heavily cached; I've heard that if you make a change to Info.plist, you have to rename the app bundle and name it back to have the changes picked up by the launcher.
Good luck!
Here's an idea: use Eclipse >=)
..but seriously, something got corrupted in Netbeans' metadata/cache data files. You cleared a couple of them but there may be others elsewhere.
Try comparing the launch command in your shortcut to what you're typing in the console. Are they the same?
To find the root cause, I would check the NetBeans logs, as detailed here
/Users/yourname/Library/Application Support/NetBeans/7.2/var/log/messages.log
And if that doesn't help, I'd archive your project(s) and put a clean install of NetBeans on your machine, and then import the archived project(s) back into NetBeans.
I have added a 2.45mb jar file to my Android eclipse project and now I continue to get "Conversion to Dalvik format failed: Unable to execute dex: Java heap space" no matter what I do.
I have researched online, and was informed to update my eclipse.ini to increase my Java VM heapsizes. I have done this for all the values in eclipse.ini and I continue to get the build error.
Any ideas?
Modify the -XmsAm and -XmxBm paremeters in eclipse.ini so that they are large enough. The default is -Xms40m -Xmx384m. Try changing them both to -Xms512m -Xmx512m and restart eclipse to see if that helps. If not, continue to increase the values and restart eclipse until either one of two things happens:
Your build completes.
Eclipse won't restart because you don't have enough memory.
eclipse.ini is located at /etc/eclipse.ini in Ubuntu (assuming you installed Eclipse from the Ubuntu repositories).
For MAC please see:
Finding eclipse.ini is a wee bit tricky. To locate it, right-click on the Eclipse Application icon and select "Show Package Contents", then double-click on the "Contents" folder and then double-click on the "MacOS" folder, the home of eclipse.ini
https://confluence.sakaiproject.org/pages/viewpage.action?pageId=61341742
Sometimes checking the .jar library in project properties also causes this problem. In that case, try the following:
Right click your project.
Go to Properties -> Java Build Path -> Order and Export.
Uncheck the check box against your included library.
Press OK and run the project.
On doing this Eclipse will take only the classes which are needed in the code, from the jar instead of storing all the classes from the jar.
All above answers are perfect , but you can try one more thing and that is fast and easy ,
close all your unnecessary open projects in Eclipse workspace and then Restart Eclipse .
You can also increase the -XmsAm and -XmxBm paremeters in eclipse.ini .
Go to your project properties and remove your added libraries from Java Build Path hit ok,
then again re add them. I also faced this problem.By doing this I solved this issue.
Important addition:
The solution didn't work on my Windows (probably memory allocation issues), but did well on a Linux on same machine. So installation of another OS would help you or Windows re-installation.