Community
Participate
Working Groups
It would be useful (for PDE) to expose the os/ws/arch constants in BootLoader. Proposed names would be: String[] getOSList(); String[] getWSList(); String[] getArchList();
Why is this useful? It's a dangerous game to be exposing these values in general. It requires us to have complete knowledge of all OS and ARCH configurations that Eclipse will run on (which we don't). We would be playing a constant game of catchup to maintain these lists. For example, we only currently have an ARCH constant for x86. These constants also bind us to supporting values that the JDK itself does not guarantee. It is not specified anywhere (that I know of) what value is returned for the properties os.name and os.arch across VM implementations. We already play games internally to handle some VMs that print different values for x86 and SunOS than Sun VMs do. This could get much worse as the number of target platforms increases.
PDE has a preference page that allows users to set the values of os/ws/nl/arch variables. By default, the combo boxes are set to the values returned by the design-time instance BootLoader, but can be changed. This is important for resolving variables in library entires that contain $<var>$ entries, like SWT ($ws$/swt.jar). Since PDE uses combo boxes, it must populate these combo boxes with some fixed list. Combo boxes are editable i.e. users can set variable values that are not in the list. However, it is not appropriate for PDE to supply the list values because BootLoader knows better what values are currently supported. As new values are added, the list can be updated. We are not asking for a list of ALL values that will EVER be supported. We are asking only for the list of values that are CURRENTLY supported by the platform. Users developing code for new OS/WS/ARCH combinations can enter the values manually (i.e. not from the list).
Is it even possible for the OS and ARCH values to change between development workspace and runtime workspace?
It is possible although not for the purpose of launching. This is the scenario: 1) A large plug-in contains some common and some platform-specific code 2) The developer starts with default (design-time) variables. All the classpaths are resolved to point to Win32 libraries. 3) The developer switches target environment to linux, updates the classpath. All the libraries now point to linux versions. Of course, the developer cannot run (on Windows) but can compile correctly. The plug-in in question is SWT.
Adding Jeem to CC for comments on API changes.
/** * Returns a list of known system architectures. * <p> * Note that this list is not authoritative; there may be legal values * not included in this list. Indeed, the value returned by * <code>getOSArch</code> may not be in this list. Also, this list may * change over time as Eclipse comes to run on more operating environments. * </p> * * @return the list of system architectures known to the system * @see #getOSArch * @since 2.0 */ public static String[] knownOSArchValues(); /** * Returns a list of known operating system names. * <p> * Note that this list is not authoritative; there may be legal values * not included in this list. Indeed, the value returned by * <code>getOS</code> may not be in this list. Also, this list may * change over time as Eclipse comes to run on more operating environments. * </p> * * @return the list of operating systems known to the system * @see #getOS * @since 2.0 */ public static String[] knownOSValues(); /** * Returns a list of known windowing system names. * <p> * Note that this list is not authoritative; there may be legal values * not included in this list. Indeed, the value returned by * <code>getWS</code> may not be in this list. Also, this list may * change over time as Eclipse comes to run on more operating environments. * </p> * * @return the list of window systems known to the system * @see #getWS * @since 2.0 */ public static String[] knownWSValues();
I would advise changing APIs to match Java naming conventions as follows: Change: public static String[] knownOSArchValues(); public static String[] knownOSValues(); public static String[] knownWSValues(); to: public static String[] getKnownOSArchValues(); public static String[] getKnownOSValues(); public static String[] getKnownWSValues();
"get" and "set" are standard prefixes for accessor methods. In a case like this, where there is no field being accessed (not even conceptually), it is common to not consider such methods as accessors. The names without the "get" prefix are shorter and just as clear as the ones with.
Implementation for OS (and WS) basically is the following: if (user didn't specify -os) then if (System.getProperty() value is one we know) then os = BootLoader.constant_value; else os = BootLoader.UNKNOWN; endif endif Should we create an ARCH_UNKNOWN constant as well to remain consistent?
osArch cannot be unknown - if user does not specify, it is whatever the value of the java "os.arch" System property.
Fixed and released. Added new BootLoader API: public static String[] knownOSArchValues(); public static String[] knownOSValues(); public static String[] knownWSValues();
PDE updated from fixed lists to calls to these static methods.
