[personal profile] djinncoyote
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 http://www.epochconverter.com/)

    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.



September 2017

     1 2

Most Popular Tags

Active Entries

Style Credit

Expand Cut Tags

No cut tags