ContentWhat programming language would you use if you wanted to write some server code that needs to run on Windows, Mac OSX, and Linux?
Specifically, the software runs as a server. Ideally it will be able to run the same codebase a) on the desktop for a single user , b) on an intranet server for multiple users, and c) on an internet server farm for millions of users. While that sounds like an overly ambitious requirement, it may actually be realistic with proper consideration up front.
There will also need to be a lightweight client-side user interface for the desktop scenarios. The simple frontends could be coded on a platform-by-platform basis, but if anyone has recommendations for cross-platforms UI toolkits, I’d love to hear that too.
Ideas?
March 27th, 2006 at 10:06 am
As far as the server half of this goes, isn’t much of the point of Java that it is intended for this kind of cross-platform functionality?
How complicated does the desktop interface need to be? If it’s not too bad, I’d lean towards cross-platform UI via a web browser myself, to avoid needing to worry about particularly messy GUI code. Depending on how you build it, that should also make it fairly easy to run the UI on top of your local server as well as the intranet version. An interface for managing a server farm would be a bit more complicated, but presumably you could reuse a lot of the pieces from a single-server UI for that too if you wanted.
With that in mind, there are a lot of solutions for generating the actual HTML; you could expose all the data as XML and build the whole thing with static HTML layouts and fun little AJAX widgets if you felt like it. That could keep the server and frontend as completely distinct processes and very lightweight on the server side. I’m assuming here (as you said it needs to be lightweight) that there’s no proprietary logic in the front end of this, so a JavaScript solution would be secure enough for your needs.
March 27th, 2006 at 10:14 am
Good point about using the web browser on the client to talk to the server app, whether that server is accessed remotely over the internet or lives locally. As far as UI is concerned, that should work fine.
Java was indeed designed to be cross-platform. However, Java has really only demonstrated that capability on the server side. To date it has been far too difficult to ensure that a proper JVM is installed in a system-wide location for desktop use. But perhaps I am trying too hard to make this application trivially easy to install. I had envisioned a drag-and-drop installer on OSX, a single RPM on Linux, and whatever point-and-click mechanism is preferred on Windows these days.
March 27th, 2006 at 10:39 am
Eclipse is written in Java, works fairly well across multiple platforms, and it’s written in Java… it’s got a command line executable under Linux, an application bundle on OS X, and an exe under Windows. It’s also written in Java. I’ve seen some incompatibilities across JVM’s, but none were showstoppers. Some other apps like this include LimeWire and Azureus.
Also, if you’ve ever used IntelliJ IDEA (which I actually like a lot better than Eclipse), it was often bundled with a stripped-down JVM that it was sure to work with. I believe that the mac version still used Apple’s proprietary JVM, but the executables for the linux and windows versions ran a bundled JVM that IDEA was guaranteed to be compatible with.
March 27th, 2006 at 10:41 am
That’s a great point about bundling a JVM. And about Eclipse, something I actually run in a cross-platform environment all the time (Mac and Linux).
Doesn’t Eclipse do something clever with native compilation of the UI components, though?
March 27th, 2006 at 10:42 am
I forgot to mention that if you’re looking for an installer that works across platforms, there is InstallAnywhere, from zerog, and it works quite well. It does cost money, though.
http://www.macrovision.com/products/flexnet_installshield/installanywhere/index.shtml
I’ve been using that since 2000 or 2001, so it’s a pretty mature product. We use it for our bioinformatics grid portal, which needs to run on some pretty exotic machines.
March 27th, 2006 at 10:49 am
Rock on. Thanks for the tip about InstallAnywhere.
But the first thing I read on the ZeroG homepage is “Zero G is now a part of Macrovision”. I wouldn’t spend money on any product made by a company dedicated to aiding the MPAA cartel deny consumers their legal Fair Use rights.
I’ll keep looking around and let people know what I find…
March 27th, 2006 at 12:05 pm
Out of curiosity, what do people think about the viability of Mono as a cross-platform target for C# development? My gut tells me it is too immature, but I’d love to know C# is an alternative to Java.
March 27th, 2006 at 5:26 pm
I think that Python is a viable language for this, especially if you’re willing to have a web interface for the “installed desktop app” version. I’d also argue that a web interface can be superior to a Java interface in many situations. :)
March 27th, 2006 at 5:39 pm
Python is an interesting choice. It would really put the whole “can a interpreted language be used the enterprise?” question to the test. But in this case it will be used to build Houston, the loosely-structured message store, which is probably too performance-intensive for Python.
March 27th, 2006 at 10:42 pm
I was also going to suggest Java for the server, xml-over-http for the API and a browser for the client (with or without ajax).
As for interpreted languages in the enterprise, there are quite a few sites that generate their pages via Perl: http://www.masonhq.com/?MasonPoweredSites (not that I know Perl, but thought I’d mention it).
When you go from single user to millions of users, the ’server’ isn’t going to look the same. There are more things needed to support millions of users than a single user. See ‘Scale later’ https://gettingreal.37signals.com/
March 28th, 2006 at 6:13 pm
A quick search for cross platform java installers yields JExpress:
http://www.denova.com/JExpress
Which, despite the lame name and logo, some users claim beats InstallAnywhere. The list of companies using it isn’t too shabby either. I can’t vouch for JExpress or the motives of denova, but maybe it’s worth a try =).
As far as native compilation, I’m not really sure what you mean. All I know about Eclipse’s UI is that it usees SWT, which is not a standard Java windowing toolkit (Swing or AWT). SWT uses lightweight components mapped to native OS UI components underneath. It also leaves some amount of cleanup to the user (e.g. you need to explicitly free components sometimes, as you’re dealing with a more native library). I found earlier releases of Eclipse buggy and not too snappy, but the latest ones seem to work great. Although, I don’t really see a speed difference when I compare Eclipse to a large Swing app like IDEA, so I’m not sure whether there’s as much benefit to using SWT as IBM would claim.
March 29th, 2006 at 10:02 am
For the cross-platform client, I know a lot of programming languages have good GTK libraries. I’ve run GTK software on Windows with no problems; haven’t tested it on Mac, but I understand that GTK is available for Mac, as well. That it works on Linux goes without saying…
April 5th, 2006 at 10:05 pm
We recently decided to write a bit of client-side Java code for a project at RENCI, and I ended up doing a search for deployment options. Java Web Start looks like a pretty good option, and most JVM’s have it and the associated protocol built in:
http://www-128.ibm.com/developerworks/java/library/j-webstart/
http://java.sun.com/products/javawebstart/demos.html
http://java.sun.com/products/javawebstart/
It’s been around for a while, but I think that Java’s lack of success on the client side seems to have made it not so well known. The idea is that you just click a link, and the JVM handles downloading the latest version of your app, setting it up to run locally on your machine, installing shortcuts on your desktop, etc. You can even have it download native libraries. All you have to do is sign your jar files, and when the application runs locally it can ask the user for permission to jump out of the sandbox. I was looking at deploying SWT apps (which require some native libs), and found a nice guide:
http://www-128.ibm.com/developerworks/opensource/library/os-jws/
At the very least, it’s a nice alternative to traditional installers. All the demos ran ok on my mac, so I was rather impressed.