Hybrid Application: Java + (C++|C#|Cocoa)?

Hello everyone.  Welcome to the twilight zone.

We're getting ready to start serious work on v2 of our main application, a desktop application of moderate complexity.  Our v1 is written entirely in Java.

Of course, our main problem was the UI.  You can do amazing things with Swing (as the IntelliJ folks have proven). Unfortunately, we're just a bunch of bare-metal AI theorists and network developers.  Although we *could* go through the pain of building up a solid set of Swing talent, that's looking more and more like a dead-end road.  SWT is interesting, but way too quirky and unproven for us to stake our future on at the moment.

So, we're looking outside of Java for UI purposes, but we also have a ton of top-notch, well-tested non-UI code that functions as the core of the application.  Our current working theory is that we could continue to develop that piece in Java (which gives us great advantages for what we do compared to C++), and hook it up to a native interface layer written in C++ or C# for Windows, or Cocoa/ObjectiveC for the Mac (hell, even QT for Linux if we ever find linux users willing to pay for software!).

At a high level, this looks like a great solution.  We can link things through JNI very readily for the Windows version, and Cocoa/ObjectiveC has a wonderful native Java bridge available that makes building a native UI on top of a Java library quite painless.  And, if we ever develop the gravitas to provide the application's functionality as a subscription-based web service, we could get there really easily.

Of course, the potential potholes of this approach may be enormous -- it feels like a very large iceberg, despite its massive potential upside.

Thoughts?

monad
Friday, February 27, 2004

Have you had a look at JGoodies?
http://www.jgoodies.com/

John Topley (www.johntopley.com)
Friday, February 27, 2004

Consider server-side JSP to generate UI for client web browsers or an XML-based UI solution, if possible.

Evgeny Gesin /Javadesk.com/
Friday, February 27, 2004

Yeah, we've tinkered with JGoodies (a large part of which is now LGPL, BTW).  It's a nice compromise solution, but there are many reasons why it's just not where we want to go:

- While it goes 90% of the way towards making things look native on windows, it's that last 10% that breaks the deal.
- It makes things LOOK pretty, but that doesn't buy us any of the wonderful native widgets that OS X and Windows provides.  That's the price of running with Swing/Java that I think has hurt our productivity immensely (i.e. rolling our own components that should come with the platform).

I could go on, but I don't want to belabor the point.  I can appreciate JGoodies as being a wonderful compromise solution, but we're hoping to be uncompromising in v2 :-)

Re: XML, this is a desktop application today, and it will be for a good long while.

monad
Friday, February 27, 2004

Do you need a rich client? If not try html.
Though why do you think C++ or whatever
will be simpler? Have you tried a pilot port
to test this assumption?

son of parnas
Friday, February 27, 2004

On OS X, you can use Java to drive Cocoa. In fact, Cocoa has both Java and ObjectiveC interfaces.

Jordan
Friday, February 27, 2004

Multi-language development is hard.  Though there are ways to make it less difficult and painful, some of which you've noted.  So you're trading one problem (that last 10% of user interface that is lacking) for another (difficulties with multi-language development).

What about your application makes that last 10% of user interface so important?  Carefully consider the cost of going "native" for the user interface.  Is it really worth the benefit, or is this one of those things that is an irritation but doesn't affect the core functionality of the product?  Are you losing sales (or existing customers) because the UI isn't 100% native look-and-feel?

Should be working
Friday, February 27, 2004

What about migrating all your code to .NET's J# ?

That way you could reuse your current code and develop the UI using .NET Winforms.


However, I don't know how feasible this really is.

Just a suggestion
Friday, February 27, 2004

I don't see how converting the interface to HTML is a step in the right direction.  We'd lose more flexibility compared to just sticking with Java, and we'd have to force users to have/install a web server.

Portability of the core logic of the application is critical -- our userbase is about 60/40 Windows/Mac.  Therefore, moving to .NET wholesale is just not an option.

Yes, multi-language development is hard, but I think it might be the best way to make up that last critical 10%.  And that last 10% is critical to our ongoing success (it's probably what is keeping us from jumping the chasm, as Eric Sink likes to say) -- that's why we're looking for an uncompromising solution.

monad
Saturday, February 28, 2004

Java for GUIs has been a fustrating experience for me also. 

However, JNI & java-objective C bridge sounds hard. 

How about messaging between the java and the GUI?  Run both apps on the client machine sending XML-RPC or SOAP between.

It's not entirely clear, but it sounds like it might work.

Synder
Saturday, February 28, 2004

If you need cross-platform GUI capability, take a look at wxWindows.  There has been some discussion of it in the past here.  I know that it is available for the Mac, although I don't actually have any firsthand knowledge of it, since adding a Mac to the mix in this house is further than I want to go.  The library is wonderfully portable though.  It's truely write once, compile anywhere code.  Take a look at http://www.lazarusid.com/notes/archives/Article-21.shtml to see how I managed it for my own uses.

Clay Dowling
Saturday, February 28, 2004

Clay, thanks for the wxWindows idea -- I'll check it out.

Using some kind of RPC between a native app and a java backend running in the background is an idea that we've kicked around here also.  It's sure to be slower than hooking a UI directly up to the java core library, but I suppose if we design the external API of the RPC interface, then we could get around any bottlenecks that come our way.  I could see this being our fallback position (or our early prototyping foray).  Thanks for the idea!

monad
Saturday, February 28, 2004

Someone said "However, JNI & java-objective C bridge sounds hard."

Yeah, it does.  Good thing you don't need to have anything to do with JNI directly to integrate Cocoa and Java.  Java is the other language supported by Apple for Cocoa development, and while there are some pitfalls it's actually really easy and clean to integrate your pure Java code with a fancy Cocoa interface.

The framework isn't actually a separate implementation; rather, it's a JNI-based wrapper around the Objective-C framework with all of the hard work bridging everything done for you.

Email me if you're interested in going this route and I can give you some more detailed advice and fill you in on the pittfalls involved.  (Nothing serious.)  I've worked on both Objective-C and Java Cocoa projects, and the Java one was specifically done to integrate some Pure Java code with a nice Cocoa interface like you're talking about.

Chris Hanson
Saturday, February 28, 2004

"Cocoa/ObjectiveC has a wonderful native Java bridge available that makes building a native UI on top of a Java library quite painless."

I don't know if I'd agree with that. I started down the road of Cocoa + Java Bridge + Java, and it took me to a bad place. The idea was to build an application with a portable Java core (that could later be ported to other platforms) and a native Cocoa UI for the Mac.

However, there were debugger issues (sometimes it wouldn't stop on my breakpoints when executing on the event thread), the Java Cocoa interfaces were buggy (I couldn't get the text classes to do the same thing in Java as in Obj-C), and more.

I then considered the Cocoa + Objective-C + JNI + Java solution, but it had similar debugging issues. It's just too much of a hassle. I want to easily debug all the way through my application.

In the end, I simply ported all the Java code to C++ and rewrote the Cocoa UI code in Objective-C++. All the problems went away. I can concentrate on writing my app again.

The Java bridge is a very interesting technology, but I'm not sure it's ripe yet. You might be better off using more tried-and-true technologies.

Jeremy

Jeremy
Tuesday, March 2, 2004

  Recent Topics

  Fog Creek Home