Eclipse stores the "Installed JREs" information in the following 3 files.

  • .metadata\.plugins\org.eclipse.jdt.launching\.install.xml

  • This file has an entry for each item on the "Installed JREs" preferences page.
       <entry loc="C:\Program Files\Java\jdk1.6.0_45" stamp="1427484124643"/>
       <entry loc="C:\Program Files\Java\jdk1.7.0_80" stamp="1456355788382"/>
       <entry loc="C:\Program Files\Java\jdk1.8.0_92" stamp="1468644229263"/>

    The "stamp" attribute value is based on the last-modified timestamp of the corresponding folder.
    It is the number of seconds, including milliseconds, since Jan 1, 1970. (see

    This Windows PowerShell command lists the timestamps of the objects in the current folder, including seconds but not milliseconds:
       Get-ChildItem . -Force | Select-Object FullName, CreationTime, LastAccessTime, LastWriteTime, Mode, Length

    This WMIC command lists the last-modified time for a particular folder, including microseconds:
       WMIC FSDIR where name="C:\\Program Files\\Java\\jdk1.6.0_45" get lastmodified |findstr /brc:[0-9]

    This WMIC command lists the last-modified time for a particular file, including microseconds:
       WMIC DATAFILE where name="C:\\Program Files\\Java\\jdk1.6.0_45\\README.html" get lastmodified |findstr /brc:[0-9]

  • .metadata\.plugins\org.eclipse.jdt.launching\libraryInfos.xml

  • This file has a <libraryInfo> section with info on jars and paths for each entry listed in above file

  • .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.launching.prefs

  • This file has an entry for each item on the "Installed JREs" preferences page, each with an id attribute.
    The id attributes do not correspond to the timestamp numbers in the .install.xml file.
    They are probably instead set based on when the entry was added on the Installed JREs page.

    The "defaultVM" attribute indicates which entry (based on its id) should be used as the default JRE.
    (linebreaks added to below example for readability)

    <?xml version\="1.0" encoding\="UTF-8" standalone\="no"?>\r\n
    <vmSettings defaultVM\="57,org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType13,1468699399553" defaultVMConnector\="">\r\n
    <vmType id\="org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType">\r\n
    <vm id\="1468694696902" name\="jdk1.8.0_92" path\="C\:\\Program Files\\Java\\jdk1.8.0_92"/>\r\n
    <vm id\="1468699348306" name\="jdk1.6.0_45" path\="C\:\\Program Files\\Java\\jdk1.6.0_45"/>\r\n
    <vm id\="1468699399553" name\="jdk1.7.0_80" path\="C\:\\Program Files\\Java\\jdk1.7.0_80"/>\r\n

    Eclipse compares the timestamps listed in the .install.xml file to the current last-modified timestamps of the corresponding folders.

    If the timestamp listed in the file matches the timestamp of the folder, Eclipse recognizes the entry as valid.
    If the timestamp listed in the file is newer than the timestamp of the folder, then Eclipse won't recognize the entry.

    If the timestamp listed in the file is older than the timestamp of the folder, indicating a change to the files in the JRE folder, Eclipse will regenerate the <libraryInfo> section in the libraryInfos.xml file and update the .install.xml with the new timestamp.

    If you want to manually update the org.eclipse.jdt.launching.prefs file with a new entry for a new Java path, you don't have to calculate the matching timestamp number. You can simply set the stamp attribute to a value that you know is less than the actual folder timestamp (for example, Jan 1, 2014), and then let Eclipse update the files.
Everything had been working fine on Eclipse Kepler + Java 1.6. As I was building a new local environment, I decided to upgrade my Eclipse at the same time.

I downloaded the latest Eclipse version, Mars. It requires a minimum Java level of 1.7 to run. Our code is only tested on Java 1.6. So I planned to run Eclipse on the latest Java version, 1.8, while running our code on 1.6. I set the compiler compatibility level to 1.6.

First there was the Git issue as mentioned in the prior post.

Then when I tried building the code, strange things happened. First there were memory / heap space errors, and crashes. After finding the right Java memory settings to avoid those issues, the build no longer crashed, nor did it complete. It went on and on... and periodically popped up tons of windows all with the same message, while doing so. It seemed stuck in a loop.

Rather than switching to Java 1.7 and risking still having the same problem, I decided to try Eclipse Luna + Java 1.6. At least that would be a partial upgrade. (I vaguely recall a coworker having a different compile issue with Kepler + 1.7, so it's probably good I didn't try 1.7.)

Everything seemed fine with Luna. The builds worked, and the code ran ok.

Then I wanted to debug one of our other projects which uses Maven. But the File - Import menu and the Preferences window were missing the Maven entries, even though Eclipse showed Maven as being installed.

It seemed like my Eclipse might be corrupted, so I downloaded a fresh copy. With the fresh copy, the Maven entries were there! Then I installed the Spring Tool Suite in the fresh workspace, as the other projects require Spring. But after the install, the Spring entries were missing from the menus and Preferences window! Even though they had been present in the first workspace!

Now I had one workspace with the Maven entries present and the Spring ones missing, and another workspace with the Spring entries present but the Maven ones missing.

It finally occurred to me to check the Eclipse .log files in both workspaces. Both .log files showed startup errors related to the m2e and Spring components requiring at least Java 1.7. (Don't ask me why Spring seemed to be working ok in the 1st workspace but not the 2nd.)

So, after all that, I'm going back to using Kepler. There's a team tasked with doing a technology upgrade project, so hopefully they'll get our code compatible with the latest Java and then I'll be able to upgrade Eclipse.
I have a Windows 7 computer with Git installed.

In both Eclipse Kepler and Eclipse Luna, when I open Preferences - Team - Git - Configuration, and select the System Settings tab, there is a Browse button which lets me select my Git install folder. Selecting this folder causes the page to be automatically updated with the Git system-wide settings.

In Eclipse Mars, there is no Browse button, and the other buttons are disabled, so I can't load the Git system-wide settings. It seems like a bug. Has anyone else had this problem?

The Mars version of the Eclipse Help, like the prior versions, still indicates that there should be a Browse button:
If you use Git for Windows as a companion to EGit, make sure EGit knows where Git is installed so it can find the "system wide settings", e.g. how core.autocrlf is set. Go to the settings and look under Team>Git>Configuration and then the System Settings tab.

If you selected one of the options to use Git from the Command Line Prompt when you installed Git for Windows, then the location of the system wide settings is filled in with a path and everything is fine. If not, use the Browse button to locate where Git is installed, e.g. C:\Program Files(x86)\Git.

My user settings are picked up okay from my %HOMEDRIVE%\%HOMEPATH% folder. I've tried defining a HOME environment variable, but that made no difference. The Browse button was still missing.

I tried adding my Git folder to my PATH, and that made no difference either. But now I don't remember if I had added the install folder or the bin folder to my PATH... I suppose I can do that test again.

Update: A workaround for the problem is to put your Git bin folder in your PATH environment variable. See comment below.



September 2017

     1 2


RSS Atom

Most Popular Tags

Active Entries

Style Credit

Expand Cut Tags

No cut tags