Community
Participate
Working Groups
Build ID: I20071101-2000 Steps To Reproduce: According to http://wiki.eclipse.org/Execution_Environment_Descriptions#EE_Properties the ee file must be written in platform specific format. Please support a platform independent format as we will be adding a "default.ee" file to the J9 DesktopEE runtime which needs to run on a number of platforms. This would help our build, test and maintenance efforts, especially because Eclipse does not show error messages when for example the wrong path separator is used (: instead of ; on Windows) but ignores the property. More information: For example: -Dee.executable=j9 -Dee.vm.library=j9vm24 -Dee.library.path=${ee.home}/bin -Dee.ext.dirs=${ee.home}/lib/jclDEE/opt-ext:${ee.home}/lib/ext For executables add the .exe suffix (on Windows). For vm.library add .dll or .so suffix and "lib" prefix as appropriate. For directory and path separators convert / and : if necessary. Side question: what does "ee.additional.dirs" mean? I tried the J9 specific bootpath extensions (com.ibm.j9.ext.dirs) -Dee.additional.dirs=${ee.home}/lib/jclDEE/ext but the jars in that directory are not in the list of JRE system libraries. [Maybe my Eclipse version (3.4M3) does not support that yet.]
The ee file is also used by platform specific launchers. Andrew, could the launcher support a platform independent format? We use endorsed dirs, boot class path, and extension dirs to derive VM libraries. We're not using the "additional dirs", and I'm not sure what the property was initially created for. Do you recall, Andrew?
bug 216466 will track changes to the launcher to make it platform independent. I don't remember what ee.additional.dirs was meant for. The launcher does not need it, I would have assumed it was a java thing similar to endorsed.dirs or ext.dirs but I can't find anything to suggest this is the case. If neither the launcher nor JDT are using it, I expect it is safe to omit.
The ee.addional.dirs property could be used for bootstrap classpath extensions. In J9 (at least for the embedded configurations) we do have bootstrap classpath extensions as defined with the system property com.ibm.j9.ext.dirs. Files in these directories are appended to the bootstrap classpath, unlike java.endorsed.dirs which prepends. The defaults are for example lib/jclFoundation11/ext or lib/jclDEE/ext. Please note the difference to java.ext.dirs which places jars/jxes on the extension classpath. The defaults for J9 are lib/ext and lib/jcl<Config>/opt-ext. IBMers can find a detailed description in the Embedded Java/J9 Knowledge Cafe under "The Bootstrap Class Path for J9 2.3". https://w3-3.ibm.com/services/km/knowledgecafe/bpmteam.nsf/fb255e4d7bdca5b685256452006119f9/4a62220680fe0dba0725718000017662?OpenDocument
Berthold, re: >For vm.library add .dll or .so suffix and "lib" prefix as appropriate. When is the "lib" prefix appropriate? Is this something that is applicable to all VMs (not just J9)?
The "lib" prefix is a Linux convention: "Every shared library has a special name called the ``soname''. The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', ...". http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html I don't know if other VMs follow this convention.
The executable and library changes are straightforward as we know the properties that need to be changed. However the path changes are more problematic. It isn't clear when the path changes should be made. We know certain properties are paths, but what about the debug args and any additional vm args in the file? The javadoc property is a URL, so it might need to be resolved against the platform depending on if it is local or not. Is there an easier way to do this? Such as a platform specific ee (default.win32.ee) that could be packaged with it and chosen by the Eclipse launcher?
Note that except for the substitution of the ${ee.home} variable, the launcher passes all arguments to the vm unchanged. Changes for the launcher itself, bug 216466, would be about the launchers use of select properties (ie execing java, loading the jvm shared library, setting the LD_LIBRARY_PATH) but that would not change the values passed to the vm. In general I do not like the idea of having the launcher do any processing for the other properties.
The file separator '/' works on Windows in all properties in our ee files. So there is no problem in that regard. The path separator ':' does not work on Windows. ';' needs to be set in: -Dee.endorsed.dirs -Dee.bootclasspath -Dee.additional.dirs -Dee.ext.dirs -Dee.src I could not get Eclipse to run on the Linux machine I have available, so I could not verify that ';' causes a problem in paths on that platform, but I suspect so. Could somebody confirm that please?
I think that we we need some way to mark a file as "platform independent" - to ensure we allow for the case of platform specific VM definitions/layouts that do not conform to our "standard" vision. After all, that is the original intention of these files - to be able to define specific layouts of VMs. Looking at the Mac, I'm not sure how these rules apply. Suffix for libraries seem to be .jnilib and .dylib I would like defer this one post 3.4
>> I would like defer this one post 3.4 Oh well! This is not a show stopper for us - just more mindless work :-) You might postpone bug #216466 as well then.
Back to the inbox.
marking assigned for future consideration. Ken, do you think these files should be able to be platform independent?
I think they are likely platform dependent. You might get lucky and be able to share them between platforms however as you stated in the Mac case there might be simply no way to specify the same thing between two dissimilar platforms?
