determining OS

[Tom Hill]

Hi guys, does anyone know if there is an easy/quick way of determining if the operating system is windows/unix/mac based? I know you can use System.getProperty("os.name") to get the name of the operating system, but a lot of the unix based OSs are given names that dont contain: "unix" or "linux".
It seems daft to ahve to cater for every possible Operating System, when some are very similar but with different names.

Cheers!

Tom

[Ulf Dittmer]

Do it the other way round: Look at whether it contains either "mac" or "win". This doesn't catch z/OS and other exotic OSes, but it should get you started.

[Jim Yingst]

Well, the os.name system is still probably the best way to tell the OS in general. If you want a very coarse idea of whther the OS is closer to Windows or Unix, you might just check whether File.separatorChar is '/' or '\\'. Beyond that, I dunno. What sort of OS-specific things are you trying to do?

[Tony Morris]

More specifically, why are you attempting to use the Java platform to do something for another platform? It's analogous to executing dir.exe on AIX for example.

[Jayesh Lalwani]

When I was in "Applet Hell" a few years back, the best way we got around having platform-specific code in our applet was to have platform-specific applets. Most of the classes would be common among the applets. We isolated the platform specific code into a few classes, which were written for every platform, and we would package the platform specific classes into the applets. Then, we would deploy the correct applet to the client machine

I know this doesn't answer your question. But, if you have a lot of platform-specific code in your application, it is best to isolate platform-specific code into few classes and deploy platform-specific applications. It just makes debugging so much easier.

Obviously, the best case would be to not write platform-specific code at all. But, if there's no way around it, then you should try to minimize "platform creep" in your code

[Ulf Dittmer]

More specifically, why are you attempting to use the Java platform to do something for another platform? It's analogous to executing dir.exe on AIX for example.

Not quite. There are some areas where you need to deal with platform differences in order to provide good behavior on all platforms. E.g., on OS X there are a few menus you'd put in the Application menu, not in the File menu.

[Jayesh Lalwani]

Ahh!! Using Java for UI. I'm sorry you have to go through that

Won't it be better if you stored the layout of your menu in a configuration file, and write Java Code that loads the configuration file and creates the menus? You can then install platform-specific menu configuration file on the client. This way, if you have to support yet another platform, all you do is change the configuration file.

[Ulf Dittmer]

Won't it be better if you stored the layout of your menu in a configuration file

It's not as simple as that. You actually need to use platform-specific classes to accomplish some of the things that make a Java app feel like a native app, but the results are worth it. On no other platform can Java apps be made to look more native than on OS X.

And no, I don't think Java is particularly bad for writing GUI apps - it's an easy way to create cross-platform GUIs.

[Tony Morris]

Originally posted by Ulf Dittmer:


Not quite. There are some areas where you need to deal with platform differences in order to provide good behavior on all platforms. E.g., on OS X there are a few menus you'd put in the Application menu, not in the File menu.

Why would you use a OS X convention on the Java platform? What has the Java platform got to do with the OS X platform? Why not use the Java platform convention? Sounds contrived to me (albeit common).

[Ulf Dittmer]

Originally posted by Tony Morris:
Why would you use a OS X convention on the Java platform? What has the Java platform got to do with the OS X platform? Why not use the Java platform convention? Sounds contrived to me (albeit common).

One would use OS X conventions on OS X, Windows conventions on Windows, etc. The fact that it is a Java applications is precisely what one wishes to hide from the users, because they rightly expect good integration into the native OS. Using the platform Swing LAF is a big step in that direction, but not by itself sufficient. I concede that this is more often done with commercial apps than open-source ones, but it's not contrived at all.

[Tony Morris]

So you give your user an application that runs on the Java platform, pre-requisites the Java platform, and behaves like the Java platform (or at least should), except the user is not expected to know about the Java platform? The Java platform has absolutely nothing to do with the other platforms that you mention.

I only ask the question because I've seen the mistake enough times. It is most certainly contrived.

[Stan James]

behaves like the Java platform (or at least should)

Where did that come from? My customers never asked for software that behaves like the Java platform. If anything, they want it to behave like Word and Excel. Making an application in any language fit as seamlessly as possible into the OS and application suite the user knows makes great sense to me.

[Layne Lund]

Originally posted by Tom Hill:
Hi guys, does anyone know if there is an easy/quick way of determining if the operating system is windows/unix/mac based? I know you can use System.getProperty("os.name") to get the name of the operating system, but a lot of the unix based OSs are given names that dont contain: "unix" or "linux".
It seems daft to ahve to cater for every possible Operating System, when some are very similar but with different names.

Cheers!

Tom

Back to the original question (if the OP is still reading)...

Can you tell us WHY you need to determine the OS? All of the above are probably valid in particular situations, but perhaps it doesn't fit yours. The few times I needed to worry about the underlying OS, Java provided the things I needed without knowing what the OS is myself. For example, the File class provides several static fields that give the correct delimiters to use for file names and paths. There are similar variables for other common values that differ between OSes. Perhaps one of these will solve your problem without determining the OS explicitly.

Layne

[Ulf Dittmer]

Originally posted by Tony Morris:
So you give your user an application that runs on the Java platform, pre-requisites the Java platform, and behaves like the Java platform (or at least should), except the user is not expected to know about the Java platform? The Java platform has absolutely nothing to do with the other platforms that you mention.

I see where our opinions diverge. You advocate using the Java platform, and want to abstract
away the underlying OS. That's a good goal, and one which Java has achieved to a large degree.
But it is not completely possible - the File class is a good example, although it's gotten better
over the years. And there are a number of ways to tailor an app to the host OS, from changing the
accelerator key for menus to using Swing LAFs. So it's not like Java pretends that there is no
host OS, or that they are all the same.

And yes, I'm saying that users should not need to know anything about Java. They need to know their OS, obviously, but if apps written in different languages behave differently on the same OS -especially when there are established user interface guidelines- the app will be harder to use for them. Mind you, I'm talking about different users running an app on one OS each, not the same user running an app on different OSes. It would be bad for usability if by simply running an app a
user could tell that is was written in, say, C, and would have to adjust his expectations and user behavior for that.

I only ask the question because I've seen the mistake enough times. It is most certainly contrived.

I'm not sure what you mean by 'mistake' - thinking that Java has something to do with the host OS? As pointed out above, there are ways in which Java makes this connection explicit, and there are ways in which it glosses over the OS differences, which forces the developer to use workarounds in order to deliver a good native application experience. Java is a means to an end, after all. A lot of value was added to Java by providing better integration with the OS that hosts the JVM. One might even conjecture that part of the reason why Java did not take over the desktop as was once expected, was precisely because Java apps did not work like native apps.
Maybe you would prefer that a Java app delivers a good Java experience. That's certainly
worthwhile in it own right, but not the same as what I'm talking about. Both interpretations
of a good cross-platform experience are possible, and useful in different contexts.

And 'contrived', well, there are many cross-platform apps out there that do this sort of platform tailoring, not to mention a number of libraries that facilitate it. So it's not something that doesn't actually occur.
[ September 11, 2005: Message edited by: Ulf Dittmer ]

[Tom Hill]

wow, i didnt expect so many responses. Basically im just trying to kick off another application, as part of an automated testing suite im working on. The application can be installed on windows and unix but obviously they have to be executed in different ways depending on the OS.

I really just want to know whether i should be executing a sh or a cmd to attempt to start the application.

Thanks for all the input so far

Tom

[Jayesh Lalwani]

Originally posted by Ulf Dittmer:

It's not as simple as that. You actually need to use platform-specific classes to accomplish some of the things that make a Java app feel like a native app, but the results are worth it. On no other platform can Java apps be made to look more native than on OS X.

A good framework for doing something like that would be to isolate all OS specific code in a particular package, and provide factory methods that load the correct class based on the platform. I beleive the most reliable way of determining is through the configuration. Using a big switch statement to determine the OS is not only bulky and messy, it is also unreliable and limits extensibility.

So, to take the platform-specific menu as an example, you should have an interface called MyAppMenu, and 2 concrete classes called WindowsAppMenu and OsXAppMenu. You should have a factory called MyAppMenuLoader that loads the actual menu. This factory should read a configuration file to determine which class to load. You package your application in 2 differrent installations, one for Windows and one for OsX. The installation for Windows installs the configuration file that contains WindowsMenu, and the installation for OSX installs the configuration file that contains OsXmenu.
The advantage of this is
a) your platform-specific code is isolated. You isolate "platform-creep" which is definetly a good thing. Say you have some platform specific FIle Operations. Then you create a FileOp interface, and implement it for each platform. All the platform specific classes can be isolated in a single package that makes code inspection/work load distribution easier
b) the code is neater. No big switch ctatements littered throughout the code
c) The code is more reliable. Since, you are preponing the operating system decision to install time, you are making the whole proces reliable. Since, the person who is installing your application presumable knows which operating system s/he is working on, you don;t have to rely on the vagaries of each platform
d) It's more extensible. If you want a differrent menu for WindowsXP, all you do is write a WindowsXPMenu and a new installation for WindowsXP

My point is that the application shouldn't be checking for the OS at each and every step. It makes the code too messy
[ September 13, 2005: Message edited by: Jayesh Lalwani ]

[Jayesh Lalwani]

Originally posted by Tom Hill:
wow, i didnt expect so many responses. Basically im just trying to kick off another application, as part of an automated testing suite im working on. The application can be installed on windows and unix but obviously they have to be executed in different ways depending on the OS.

I really just want to know whether i should be executing a sh or a cmd to attempt to start the application.

Thanks for all the input so far

Tom

How does your application know which application to kick off?