At my work place, I was involved in building a desktop application for Mac (priority) & Windows (lesser priority). So for about 5 months, I did all my development work on Mac and now I think I have a good feel of the OS.
So the application was built using JavaFX. There were native calls to be made to some C libraries, and I used awesome JNA to do it. But in the whole, I had a terrible time working with JVM on Mac and below is a list of why it is such a pain:
Till Snow Leopard (not sure), Java came per-installed on Mac. Apple had its own bindings to HotSpot VM. But after Java 7, Apple decided to stop porting JDK and Oracle provided the built. And here starts, half the problems:
(In no particular order)
- Firstly it is excruciating working with Java 7 based desktop applications . Do not even try it on Retina display; For the font. It is horrible and blurry. I use Monospaced 13 on eclipse and it is pathetic. And I dont think any more text can ever describe how blurry and pathetic it is.
It is a registered bug which will only get fixed by Java 8 (What!!). It seems the behavior is due to the fact that Oracle built does not support HiDPI. A quick working solution is to use Apple Java 6 to run your applications if you can . For eclipse and netbeans, here.
- A lot of apple libraries such as Quick Time and others are 32-bit builds. The canon sdk, I was working with only has a 32-bit build available. And only a 32-bit JVM can do native calls with 32-bit libraries. Apple Java 6 is a 64-bit VM and can be run in 32-bit mode using `-d32` jvm argument.
The issue: Java 7 no longer supports `-d32` option. Which means you cannot use it to call 32-bit native libraries. And this breaks half the code. Hence, I simply cannot use Java 7 for development.
- It is buggy. Our client was Norwegian. Obviously, he had a lot of files named in Norwegian. The issue: Java 7 could not detect files that were named with non-ascii characters (norwegian). (This was caught at the client side and believe me it hurts when you see this happen). It was a bug which was solved but the damage was done.
And then it was corrected. But during testing, I realized that the DirectoryChooser of javaFX did detect them, and on user selection, weirdly returns null instead of file. I have submitted the bug. But again it was painful telling the client not to use files/directories with Norwegian characters. And I had no time building a custom component.
With all the above, it was still important to use Java 7. We wanted to build a cross-platform application and had no developer resources to write them separately for each OS. This made C/C++ out of picture. We did not want to use Adobe Flex (license & future maintenance issue). Not python, as no one in team knew it and we all were comfortable with Java.
We built on Java 7 because:
- Apple does not give license to redistribute VM along with application. But my company people wanted to port it along. Hence Java 6 cannot be used.
- We wanted to use JavaFX (awesome MVC UI toolkit) and not Swing. JavaFX looked promising (which actually is) and hence the decision was taken. But unlike windows, JavaFX build is only available from Java 7 on Mac. Hence we are stuck with it now.
The only positive was this small issue, which worked well on windows and not on Mac.
PS: There are a lot more and will keep adding up the list as time permits.