if you wanna code a desktop application in java for windows, mac and linux, will the code be the same for all of them?
and you just change the GUI so that the Windows application will be more Windows-like and so on?
how does it work without digging into details?
You use generic UI libraries that render the same UI on different platforms.
Some use their own drawing/widget construction, others abstract the native UI elements.
Simple.
Examples: Swing, AWT(with bugs, read below) and QT(with caveats) or SWT (people seem to like it)
Not only will the code be the same, but the compiled result will be the same (the output of javac, the java compiler), at least theoretically. The JVM installed on each operating system takes care of translating the compiled output (called "bytecode") into the platform-specific code. This means, for the most part, you can e.g. design and build your Java app on Linux and run it on Windows or Mac.
One of Java's selling points is that is is "Write Once, Run Anywhere" (pretty much).
The compiled bytecode is executed by the Java Virtual Machine (JVM). The JVM is specific to the platform that it runs on but the same bytecode can be executed by any platform that has a JVM. The code does not have to be recompiled.
Swing is Java's cross-platform GUI toolkit. You can configure it so that it has a GUI that looks the same across different platforms (it won't look native on any of them), or you can tell it to use the most appropriate look-and-feel for the platform that it is executing on. So if you run on Windows it will look like a Windows app, if you run on OS X it will look like a native Mac app.
If you want your application's UI to be "windows-like" on Windows, "Mac-like" on Mac and so on, take a look at the SWT and RCP technology that underpins Eclipse. SWT in particular has the kind of properties that you want.
The downside (if you want to call it that) is that your application won't be able reuse any existing AWT / Swing based libraries. And obviously, you've got to learn how to use the SWT stack.
People used to say that Swing did not produce native results on different platforms. Apparently that's all changed, and Swing is now nigh-perfect. Go Swing! This is great news for those of us who love Java (and Groovy! and JRuby!). This may be premature, but it's in the works.
Java will work and well, and you will be able to write and compile once for the VM. However, you will need to package your app for each platform differently if you want the user to not have to type java -jar app.jar. On OSX you need to make a .app (very simple) and there are many launching options for Windows and Linux, too. Also Java WebStart is another possibility.
Hope that helps.
Edit: Getting your Swing to work on OSX and seem native takes some extra steps. See here.
The code itself will run on any platform that has a Java virtual machine, because all the JVMs translate the same exact bytecode into OS-specific machine code.
As for the look and feel, there is a method (UIManager.getSystemLookAndFeelClassName()) that allows you to make your interface use the GUI that matches the rest of the OS. It returns different results on different OSes.
If you factor your application into three different layers:
Then you can use the same code for all three on different platforms, but it will only 'feel' right on one of them. Typically the logic and presentation will not change, but the interaction will need to change if the Java application is to mimic native applications.
For example, the default on OS X is to have the menu at the top of the screen, and the default on Windows and Gnome is to have the menu at the top of the window. Gnome usually has application properties under edit, Windows under Windows and OS X under the apple symbol ( or something ), so the details of the menus shouldn't be the same. Each system has different layout and font rules, only some of which are implemented by Swing native mimicking look-and-feel.
Another option is to make a web application, which takes quite a bit of the variation away - you don't have windows, menus and dialogs as such buttons are provided by the browser so aren't your problem, and users don't expect platform specific behaviour from web applications.
In summary, yes, java is generally write once run anywhere. It's "Skinned" to fit the platform. You do have to pay attention to hardware information like screen size if you expect it to work on a phone.
Note that it also will be running on cable boxes--I'm working on some of that stuff.
Even interactions with platform specific elements are often in the same codebase--so if you have a library that detects the existence of the windows toolbar, you might detect it and support it if it's available, but the code would just not detect it on a mac (or might use a different library).
A competent engineer would not, however, have to recompile for a different platform.
If your code interacts with the file system or invokes JNI, it won't be the same.
I'm presently working on a Web app where we routinely do our development on Windows but testing and production is on Linux. In the past I've written GUI apps where the exact same code ran on both Windows and Linux. I've never done Java on a Mac, but I presume it ports as well there as between Windows and Linux.
The beauty of Java is that 90% of the time you don't even have to think about it. You just write code that will work on the platform you're developing on and it will port magically.
The only thing that is routinely an issue for me is working with files. There are some features in Java that help, but sometimes you have to go out of your way to take advantage of them. Like, file names are different: On windows you have a drive specifier (like "C:") while on Linux you don't, and on Windows you separate directory names with backslashes while on Linux you separate them with forward slashes. There are functions to let you handle this with generic code but there are times when that's a pain. Etc.
If you want to use specific fonts, you won't find the same fonts on different platforms. But you can't rely on finding specific fonts on different boxes with the same OS. If you want to use specific fonts, you really need to check what fonts are available on the box and let the user select the one they want or have the program examine font characteristics to pick one.
I'm hard-pressed to think of anything else that's been an issue for me. I'm sure if you try you can come up with things to break on one or the other, but those are the only things I recall ever running into without looking for trouble.