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:
/src
/lib
linux/
jars/
config/
windows/
jars/
config/
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):
/
*yourjar*
*launchfiles*
/lib
jars/
config/
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.
JSR-310 is based on nanoseconds, not milliseconds. As such, the minimal set of sensible methods are based on hour, minutes, second and nanosecond. The decision to have a nanosecond base was one of the original decisions of the project, and one that I strongly believe to be correct.
Adding a method for millis would overlap that of nanosecond is a non-obvious way. Users would have to think about whether the nano field was nano-of-second or nano-of-milli for example. Adding a confusing additional method is not desirable, so the method was omitted. As pointed out, the alternative get(MILLI_OF_SECOND) is available.
FWIW, I would oppose adding the getMillis() method in the future.
Best Answer
You might consider always storing the times in UTC. Then have your code logic handle conversions per timezone appropriately. IMO this is easier than trying to convert to other arbitrary timezones, and many code libraries have built-in options for UTC. This also has the benefit of still working if your data storage (database?) server is ever moved to a new location -- or even the cloud.