I'm working on a normal Java/SWT desktop application I'm planning on distributing to the three primary PC platforms (Windows, OSX, Linux). Obviously, there are slight differences between them, mainly having to do with files.

What's the best way to keep those differences separate? I'm thinking three different SVN branches (win, osx, linux), and trunk for development, but then how do I update the branches without overwriting the differences? Do I need to define a platform constant instead at compile time?

And then, of course, there are different versions of libraries (i.e. SWT in my case). How should those be handled? Where should I keep the compiled byte-code ".jars" files?

  • "Obviously there are slight differences between them, mainly having to do with files." Really? Can you enumerate them? – S.Lott Jan 26 '11 at 19:25
  • For one, file addressing. /home/user/Documents/file.txt vs C:\Users\user\Documents\file.txt. Also, there is no /tmp/ in Windows. – Jonah Jan 26 '11 at 19:28
  • 2
    "/" works on Windows too. Note you can ask for a temporary file name and sneakily change it into a identically named folder, in which you can have your workfiles. – user1249 Jan 26 '11 at 20:04
  • @Thorbjørn: that's good. But I don't quite understand what you're saying about /tmp/. "Identically named folder"? – Jonah Jan 26 '11 at 20:31
  • I believe he means a trick where File f = File.createTempFile() creates a new file with a guaranteed-unique name, then you use f.delete() and f.mkdir() on it. – Darien Jun 6 '11 at 7:00

For the example you gave (file paths), you should use a configuration file. You can have one for each platform, or one big one with settings for all platforms. I'd lean toward the first option, because then you can just use that one file and all the paths would be set. Java has a rich set of methods to construct platform independent file paths; use things like File.separator rather than \.

Generally in Java you don't need to have separate projects for separate platforms - that's why the JVM! Use specific components for only those parts of the application that are platform specific. In my experience, I have not seen anything in Java intself that needs to change for different platforms. Interacting with the filesystem is trickier, but there are ways around that as described above. That being said, you should still test on the platforms you intend to deploy on to be sure that everything does work - sometimes there are subtle differences in JVMs for specialized applications.

My recommendation for jars and other platform specific components is to have a directory structure look something like this in your VCS:


Then in your build scripts, only include the folder you need for the platform you're building for. I'd include the folder as lib in your build, so for a Linux build you'd end up with (as a suggestion):


Zip that whole thing up and unzip it where you want to install. That will avoid having to specify paths more than once in code at the expense of a slighly more complicated build process. You could probably put that in a windows installer, too.

  • When you say "configuration file", are you referring to java.util.Properties? And what about detecting disk drives/media (i.e. thumb drive, memory card, etc.)? – Jonah Jan 26 '11 at 19:47
  • 1
    You could use Properties for it if you want - the file is up to you as you provide a stream for it to write to. As for drives, if you just need to allow the user to find files use an existing Dialog - it already exists. If you need more than that, create an interface and use separate jars to include the specific classes you need. See my edit for an idea of how to handle these. – Michael K Jan 26 '11 at 19:56
  • The first directory structure: would /lib be along-side of my /src directory? When you say build script, you mean the equivalent of "Export Jar" in Eclipse? And the last structure, is that what the jar would look like, or files outside of the jar? – Jonah Jan 26 '11 at 19:58
  • 1
    In Eclipse, you could create a custom ant script that would build the project for you. I believe you would need to replace the "Java Builder" script in the Properties->Builders on the project. Does my edit explain the other question? – Michael K Jan 26 '11 at 20:04
  • 1
    Jars can't be in other jars, sorry about that. You could use fatjar, or create a zip file with your jar, launch files, and that folder. I'll edit my answer to reflect that. You'd have to change the classpath - I would do that in the launch with -classpath. – Michael K Jan 26 '11 at 20:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.