The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Dilemma over Java vs Native Code

Hello.  I am starting a new desktop application that will be commercial.  Ideally, it would be cross platform and run on Mac, Linux, Windows.  Java seems like a nice fit since I would more than likely make a mobile version in Java as well.  However, I have searched the 'net and seen quite a bit about decompiling Java and having to use a source code obfuscator, etc.  Then reading other posts about this and people warning not to use a code mangling tool.

I am used to just writing Windows apps in C/C++ and am also very familiar with reversing/decompiling native Windows apps (which can yield hundreds of thousands of lines of code, especially tricky when looking at C++ code).  So I know that in regards to someone being easily able to copy native C/C++ code is not nearly as big of a deal as it is with Java.

So, I feel like with Java it would be much less trouble having a consistent GUI across multiple platforms.  However, I do not have much experience with distributing anything in Java out in the commercial world.

Does anyone have any experience or thoughts they could share that might relate to this?  Would it be better to write the program under Windows and then attempt to port it to other platforms later while just using C/C++?

I know about wxWidgets, etc.  But I am thinking of either just using Java or dropping other platforms and keeping the application Windows based.

Any feedback is much appreciated.

Thanks!
andrew Send private email
Friday, July 11, 2008
 
 
Unless you're keeping some intense trade secrets in your code, obfuscation is generally enough to keep people out of your work.

Piracy rates are typically lower in B2B commercial outfits, and obviously the principle "if somebody wants it bad enough, they're going to get it" still applies.

Friday, July 11, 2008
 
 
I had a bad experience several years ago writing a Java app for Windows and Mac.  I'm sure things have changed, but at the time, Apple's support for Java was significantly behind Windows.  This resulted in several important functionalities not being available: cut & paste and the print dialog box are the ones that come to mind, but there may have been others.  It seemed like Java was the ugly stepchild of Apple, and it got minimal developer attention.

Second, the Java implementations were slightly different.  Things that worked fine on Windows didn't on Mac, and vice versa.

Finally, we really tried to make the Windows version have a Windows look and feel, the Mac version have a Mac look and feel, not both have a generic Java look and feel.  (On the theory that our users would use one platform or the other, and would expect our program to behave like other programs they were used to.)  In most cases this was possible, but there was definitely some Mac-specific and Windows-specific code, not just write once run anywhere code.

I won't even tell you about the hassles we had talking to Apple and trying to find out when/if they would ever release an update.

The nice thing about C++ is that it's kind of the default language for both of those platforms, and you can get at the platform API easily.  Depending on what you're doing, you might have 90% common code and 10% platform specific.  Or you might have almost all GUI code and little back-end.
Michael Send private email
Saturday, July 12, 2008
 
 
If you're wanting to do well on the Mac then I'd highly recommend NOT using Java. On the Mac, users expect an app to look and behave like a Mac app, so they want the standard print dialogue, standard open/save dialogue, standard font picker, their text fields to have the system wide spell checking etc. It's much easier to do that either by writing a Cocoa GUI, or to some extent using one of the many "cross-platform yet uses native elements" APIs. The reality with Java is "Write once, suck everywhere".
Martin Pilkington Send private email
Saturday, July 12, 2008
 
 
Desktop applications written in Java just don't look good. I'd avoid that.
piaskal
Saturday, July 12, 2008
 
 
You get the impression that Java is not adequate for commercial apps..?
Eddy Vluggen Send private email
Saturday, July 12, 2008
 
 
Have you considered using the Qt framework? it is C++ based and has a proven record of cross platform support with a consistent appearance.
Pablo Send private email
Sunday, July 13, 2008
 
 
> Desktop applications written in Java just don't look good.

Actually, some do ;o)
Yanic Send private email
Sunday, July 13, 2008
 
 
@Yanic, I've yet to see one that does. Doesn't help that almost every Java GUI framework seems to make it as hard as possible to make a decent UI, even if you have good UI design skills ;)
Martin Pilkington Send private email
Sunday, July 13, 2008
 
 
Oh well, keep looking Martin.
Yanic Send private email
Sunday, July 13, 2008
 
 
If I had a dollar for every ugly C++ program I've seen... ;)

I find it funny that when a Java desktop application is ugly people point to Java as the problem yet when a thousand other C++ desktop applications is ugly no one points to C++ as the problem.

Bad UI designers will generate ugly interfaces. It has virtually nothing to do with the language.

In my experience:

- Java will get you 90% of the way very easily. If you insist on fine-tuning the interface the last 10% of the way it will cost you days :( This is the unfortunate result of the built-in components being weighed down by spaghetti code.

- Sun did not invest enough to fine-tune the interfaces so they look 100% on all platforms so you will end up with some ugly corner cases (especially with JFileChooser). Most of the time there are workarounds but you will waste days getting this right. That being said, Sun has made huge strides in improving this situation and Java6 looks a lot better than previous releases (JFileChooser is still horribly broken in my view).

The funny thing is that, in complete contrast with the built-in components, it's extremely easy to write your own GUI components in Java. It's so easy it's actually fun to do so ;) But you're not going to want to reimplement all of Swing...
Gili Send private email
Monday, July 14, 2008
 
 
Obviously, there is no _easy_ way to please every user on every platform. If you don't already have experience building good looking cross platform applications then I'd say just build your 1.0 for your main target platform (Windows) and worry about the rest later.

Do yourself a favor and don't go through a lot of pains for Mac and Linux-desktop users. They're a very small, very loud minority. Saying that the mac has a 10% market share would be generous...and how many out of those would be in the market for your software?

Saying that Linux desktop users have a 1% market share is being very generous. Also, keep in mind that Linux users don't like paying for software, so if your software becomes at all popular, you can bank on the fact that someone will build an open-source clone of it anyway.
Wayne Bloss Send private email
Monday, July 14, 2008
 
 
"Do yourself a favor and don't go through a lot of pains for Mac and Linux-desktop users. They're a very small, very loud minority."

But in the case of the Mac, a very profitable minority if you take the time to do things right.
Martin Pilkington Send private email
Monday, July 14, 2008
 
 
Why, are they willing to pay more for the same software? For example, XyzTools for windows 59$, for Mac 89$ ?
Yanic Send private email
Tuesday, July 15, 2008
 
 
If it is a high quality piece of software yes, they are also more likely to buy (can't remember the link but there's a study that was done a year or so ago showing that Mac users on average buy 3 times as much software as other computer users).
Martin Pilkington Send private email
Tuesday, July 15, 2008
 
 
Sure. Windows users Windows and MS Office.

Mac users might buy OSX, iWork, MS Office (for Mac), Parallels, Windows, and MS Office (for Windows). But they get a tightly integrated stack for their trouble, right?
PeterR
Wednesday, July 16, 2008
 
 
Thanks for the input!  I think I am going to stick with native code and port to other platforms later on (but still build all of my native functions in a cross-platform friendly way for later on).

I am just coming down from a Unix/C way of thinking from the past couple of years.  And that's probably why I was so caught up with having my new app be cross platform.  I was even considering doing my own controls in OpenGL at one point and just getting enough code on each platform to open a window and start drawing (No comment neeeded).

I thought Java might be an easy way to do this as well, but was concerned that since Java is so easy to reverse/decompile, why would I write an app with those properties?  Or spend so much time running everything through obfuscators, etc.

But now, I think I will just target the Windows platform and port as necessary.  Since I have more experience with C/C++ in Windows, I think this will just same me more time all the way around than going with Java.

I guess I just like C/C++ better, personally.

Thanks again for some valuable insight.
andrew Send private email
Wednesday, July 16, 2008
 
 
Keep in mind that you will not find many Mac users for a B2B app. It is one thing to argue about Mac users spending money for consumer apps. It is a completely different matter to argue about business users using Macs and spending money. Businesses don't use Macs unless they are running Windows on them.
uggh
Sunday, July 20, 2008
 
 
The obfustication concern is overstated. Run jad or your favorite decompiler against commercial java code from HP, Oracle, IBM or any other big name company and you'll see that they don't obfusticate. Why? Because the obfusticators and compressors on the market universally stink -- they simply don't hide anything. Same could be said for code in any language though -- if I want to know how you did something, I'm going to figure out a way to reverse engineer your stuff.

Here's the other part to my argument -- even if I do decompile your code, what harm is it doing to you? If I take your code and release a similar product, you'll be able to identify that fact just by decompiling my code ;-) If you simply take apart my code for your own curiosity, I'll never know the difference, so it doesn't hurt me either. Could someone decompile my code to figure out a way to create a license hack? Sure, but the people who would do that weren't going to pay for the license *anyway* so I'm not really losing money there either.


Now, back to your main question -- portability. C code can be very portable. Just make sure the business function and the UI are separate. Use cocoa on the Mac to put a native objective-c front end on the same C code that you'll put say a QT front end on for your windows and/or unix customers. You may have to maintain three or so separate UI layers, but you'll have the functionality in common on the backend. And, regardless of language you'd probably end up wanting separate GUI code so that you can appease each market -- Mac, Windows, and unix people have different needs and expectations.
why obfusticate?
Thursday, July 24, 2008
 
 
May I suggest some reading on the topic (I am the author of both articles):

http://www.excelsior-usa.com/articles/java-to-exe.html
http://www.excelsior-usa.com/articles/java-obfuscators.html

If you do not like Swing GUIs, SWT and hence Eclipse RCP use native widgets where available. Look at the best Eclipse RCP applications here:

http://www.eclipse.org/org/press-release/20080318_AwardsWinners.php

Finally, there is a Java binding for Qt called Qt Jambi:

http://trolltech.com/products/qt/features/language-support/java

HTH.
Dmitry Leskov Send private email
Thursday, July 31, 2008
 
 
"Thanks for the input!  I think I am going to stick with native code and port to other platforms later on "

It would be better to start doing two or more platforms at the same time so that your code doesn't get fixed tightly to one platform.  Later on it would be difficult to separate platform specific code.
dd
Saturday, August 02, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz