"Java shareware". Ever seen any? Probably not, and I know why. Unfortunately I even "have known why" and went ahead and wrote my latest app in Java anyhow. The problem is that a Java application is interpreted by a virtual machine. The code is never "really" or "fully" compiled. Rather, it's compiled into the bytecodes used in the Java virtual machine and the VM finishes the job moving it to pure machine langauge. This has the added problem that Java is relatively easy to decompile, as it's not in true native machine langauge. The bytecodes closely resemble the original Java code so that they're easy to move from one platform to the next.

In fact, it's so easy to decompile that it's only one step away from being an interpreted langauge, like the original BASIC. Remember playing some old Commodore 64 games and hitting "break"? Bam, you were right into the code. You could LIST the contents and even change lines to change what happened in the game. Because the BASIC app was never compiled at all, the creators' had to ship the code as the application. Ultimately, as I'll continue to explain, Java applications are quite nearly in the same boat.

Here's a partial example taken from Furthurnet, which is open source so they shouldn't mind us taking a peek. Remember, this is from the "binary", not from the actual [open] source.

public void hyperlinkUpdate(HyperlinkEvent hyperlinkevent)
  {
    if(hyperlinkevent.getEventType() == javax.swing.event.nt.EventType.ACTIVATED)
    {
      String s = hyperlinkevent.getURL().toString();
      String s1 = "http://furthurnet.com/pcplink.html?";
      if(s.startsWith(s1))
      {
        s = s.substring(s1.length());
        String s2 = URLDecoder.decode(s.substring(0, s.indexOf("&")));
        String s3 = URLDecoder.decode(s.substring(s.indexOf("&") + 1));
        try
        {
          QueryPanel.download(new QueryResultItem((XmlObject)XmlParser.parse(s3).elementAt(0), s2), null);
        }
        catch(Exception exception) { }
        return;
      }
      JEditorPane jeditorpane = (JEditorPane)hyperlinkevent.getSource();
...

Not too bad, eh? Doesn't do a great job of commenting, of course, [because it can't, naturally,] but all in all pretty good source. We'll ignore Furthurnet's horrible exception catching code for the time being.

You can use bytecode obfuscators like Retroguard to make things a little more difficult. Then the names of events and some variables become a little more generic and difficult to read and the like. There are more things like the Strings named s, s1, and s2 above. But the source is still all there. If someone wants to crack your app, they've essentially got the code to work with, which is a dream spot for crackers.

Even when you use something as "trite" as Visual Basic, which I enjoy using, you're going to have a truly compiled application. People can wade into the machine langauge if they know assembler, but this is a much better way of hiding the way you process, say, license keys, which is pretty important to keep private. The level of effort is just too high for your typical dimestore hacker when something is compiled to native bytes.

Of course Java is shooting for crossplatform applicability, and that strikes native bytes almost completely out of the equation. Java programmers' reply to the "open source, like it or not" quandry seems to be, "Anything, even something protected by hardware, is hackable." Well, sure, but it's all about time. As a software vendor, I want to make it difficult enough to deter most dimestore hackers and make it take someone who's really got it in for me long enough to hack the app and distribute it to the pirates that would use it that I can get another version out in the meanwhile.

This is also, I believe, why Java and open source go together so well. The source is already there. It's no wonder most of the Java apps I use daily (Furthurnet and Netbeans for the most part, but there are some other small ones I grab once in a blue moon) are open source. And it's no wonder I've never used, that I recall, a commercial Java app. The only apps that can make it are the extremely expensive ones, like enterprise-level IDEs and server code, where the stakes are high enough and the customers are select enough that nobody's going to fudge.

Is it okay by me that people hack apps? Absolutely not. Is it stupid for me to assume they won't? Absolutely so. To think any other way would be to lose money. And the prospect of accidently creating a successful application has already got me thinking about porting the code to C# for a Windows version -- though I suppose .NET might behave like a VM as well. I wonder how easily it can be decompiled!

Quick update: Yep. It can. Thought so. Wonder what this means for .NET shareware writers and other small software companies. Definitely a vote for web services, like it or not, where you can hide the code on your server. The web services is, unfortunately, what I keep coming back to thinking is the best model for creating applications that can't be cracked [quite so very easily].

More about decompiling .NET here and here.