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.
Localization and internationalization,
Keeping the strings external allows them to change (read: translated) without needing to recompile (just a relink at most, and just dropping in a new folder at best).
Best Answer
Disclosure: I work for appMobi.
There are many similarities between the two, in fact some of appMobi's functions are built on PhoneGap. Fundamentally, they both encapsulate HTML5/CSS3/JS into a webview that is exposed to the user from a native "Container". They both offer an API that lets you access the device's OS in a way that is impossible for a web app to do.
The bulk of the differences stem from the fact that PhoneGap was created as an open source project by many people who were each trying to solve their own problem or support development on a different platform, and appMobi has focused on creating a programming ecosystem that allows development of cross platform apps using HTML5. appMobi has focused on iOS and Android as its targets, and was the first to offer a cloud-based "build" system that accepts your HTML5 code and encapsulates it to create app store-ready binary files for a variety of app stores. Following the acquisition of the PhoneGap dev team by Adobe, there is now a paid cloud build service similar to appMobi's.
PhoneGap follows the typical open source model of allowing the developer to assemble their tool set using whatever tools they can find. There is no integrated PhoneGap IDE, emulator or debugging service. To be sure, these things exist, but they are not integrated and require you to build and learn them individually. In trying to present a fully formed HTML5 development toolset, appMobi provides an integrated toolset - IDE, emulator, local and remote debugger, and the build service mentioned above.
Because mobile games are well over 50% of the top 100 mobile apps, appMobi has developed numerous technologies that allow HTML5 mobile apps to perform well enough to compete with natively coded games. These include - directCanvas (10x graphic rendering acceleration), MultiSound (Sound acceleration, looping, one shots, etc), Social Badges and Leaderboards, and cross platform in-app payments. PhoneGap has no game acceleration or support tech like that.
Finally, PhoneGap is solely a development tool. When you use PhoneGap build to create your IPA or APK file, you are done. appMobi's goal is to enable HTML5 to compete with iOS and Android as a mobile platform, so appMobi has created a number of cloud services that deliver value to your apps when they are used on the user's device. In effect, appMobi fills in the gaps that HTML5 has, making it competitive with iOS and Android. These services are all cross platform (you write it once and it works on iOS/Android/??). They include rich media push messaging, in-app payments, user authentication, gamification, hosting, and user activity analytics.
PhoneGap's tools are free, but they charge for the build service. appMobi's tools and build service are free, but they charge when your app becomes successful (over 10,000 monthly users).
More recently, the HTML5 development tools created by appMobi (XDK, Build System, Debugging tools, jqMobi) were acquired by Intel and are now part of the Intel HTML5 Development Tools suite.
The cloud services mentioned above are still provided by appMobi. The cloud services now support apps that were developed with native iOS (XCode), Native Android (Java), and Native Windows 8 (XAML) as well as hybrid HTML5 (appMobi or PhoneGap), and good old web apps.