BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person or online.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or online.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News InfoQ Article: Java, .NET, but why together?

QCon New York (June 13-15): Learn best practices from senior developers at early adaptor companies.

InfoQ Article: Java, .NET, but why together?

Bookmarks

Oct 10, 2006 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more
The Java vs. NET war is over. In this article, Ted Neward looks at how we can leverage the strengths of each together, such as using Microsoft Office to act as a "rich client" to a Java middle-tier service, or building a Windows Presentation Foundation GUI on top of Java POJOs, or even how to execute Java Enterprise/J2EE functionality from within a Windows Workflow host.

Read Java, .NET, but why together?

Ted Neward is a noted author and speaker in both the .NET and Java communities, and is perhaps the bes authority to speak on the subject. Ted introduces:
Over the years, there has been a fair amount of discussion about both of these environments, much of it highly inflammatory to one side or another, and almost none of it very useful. After all, statements like "My language is better than your language", or "My platform runs faster than your platform", or "You guys suck", are perhaps fun topics to toss around during cocktail parties and conference panels, but they’re hardly a productive discussion leading to meaningful software development. Even once past the politics, posturing and tomato-throwing, to try and have meaningful discussions of Java and .NET working together, the typical conversation moves to high-level buzzwordology like "Web services", "Enterprise Service Bus" or "Service-Oriented Architecture", with almost nothing concrete to show for it. Even then, once past the high-level discussion and into the low-level details, the talk is typically of SOAP and WSDL and WS- protocols, or of exchanging data through messages, or of hosting the JVM inside the CLR, or vice versa. In other words, to paraphrase the popular phrase, "You went ahead and talked about how to do it, without ever really talking about why you should do it."
This article is the first in a series of content InfoQ will host over the next 8 months exploring the capabilities of mixed Java and .NET solutions. The content will also be tagged with the 'Java plus .NET' topic, allowing you to track all the content associated with this topic at www.infoq.com/j+n, as well as allowing you to turn the topic off if you are not interested in the subject. 

Ted concludes:
Why bother with Excel when Java has formula engines? Why bother with WCF when we have JAX-WS, or with WPF when we have Java3D? Lest we be accused of favoritism or blatant Marketecture, let’s be frank and clear: just about anything .NET can do, Java can do as well, and vice versa. But let’s also be honest about one fact in particular: both platforms have particular areas of interest that they do very well. To the developer willing to set aside political dogma in favor of an open-minded discussion, playing each to its strengths can lead to some powerful benefits. Or, to quote Karl Marx rather liberally, "From each platform, according to its abilities, to each project, according to its needs."

Rate this Article

Adoption
Style

This content is in the Architecture topic

Related Topics:

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Continuity...

    by Zubin Wadia,

  • ah...been there done that - and its great!

    by Roger Voss,

    • Continuity...

      by Zubin Wadia,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Great article Ted.

      The "WPF -> Java" model, while extremely appealing, can still fall victim to versioning issues. In my opinion, unless there is formal communication between the .NET and Java camps about future roadmaps - one could have some serious continuity issues on their hands down the line. There is no guarantee that future releases of NetFX and JSE/JEE would maintain the "interoperability index" at the level it is today.

      Two developments would change this perspective for me:

      1. MS and Sun opening up an "Interoperability Community Process" (ICP).
      2. A third-party vendor producing a dual-platform IDE.

      I look forward to more certainly from both camps as it will take the "Re-combinant Innovation" era to a whole new level!

      Cheers,

      Zubin.

      Back to top
    • Re: Continuity...

      by Floyd Marinescu,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Zubin, if we're talking about WPF to Java, wouldn't the 'interoperability index' be as long lived as your particular interoperability solution? You could have WPF integrate with Java via web services, or in proc, or a variety of other means. The inter-tier communication solution is written by the project, and it seems to me that the brittleness of that solution depends on the interop solution the project chooses, or am I misunderstanding your point?

      Back to top
    • Re: Continuity...

      by Zubin Wadia,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Floyd,

      The point I am trying to make here is that the 'inter-tier communication' standard we elect to use must be supported in future iterations of .NET and Java vs. just one platform.

      For example - what if the Tango project mentioned by Ted doesn't support the latest version of WCF because it is still being updated? That would mean that I may not be able to take advantage of the latest features on the .NET platform because my Java tier is getting upto speed. This scenario, ofcourse can apply conversely also.

      Needless to say, these mis-matches occur on homogeneous platforms too - but I believe the probability of it occuring with a hybrid setup is higher. Atleast for now.

      Cheers,

      Zubin.

      Back to top
    • ah...been there done that - and its great!

      by Roger Voss,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      For over three years have been taking a hybrid .NET/Java approach as Ted Neward advocates in his article.

      ah...been there done that - and its great!

      Using .NET WinForms was very much the superior choice for my particular projects over Java Swing as the rich client technology. Yet Java was hands down the superior choice to use for my middle-tier - asynchronous JMS messaging was the secret sauce for my event-driven distributed software systems.

      www.humbleblogger.blogspot.com/

      Back to top
    • Re: ah...been there done that - and its great!

      by ZedroS Schwartz,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Why do say WinForms were the superior choice ? Could you develop a bit more ?

      I've heard here and there that Spring was now pretty mature and efficient, especially since Matisse, so I wonder.

      Thanks in advance

      Back to top
    • Re: ah...been there done that - and its great!

      by ZedroS Schwartz,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Oups, I was speaking of Swing and not Spring...

      Back to top
    • Re: ah...been there done that - and its great! (why Winforms vs Swing/SWT?)

      by Roger Voss,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      For user-interactive client applications that I've developed in the context of my enterprise distributed software systems, I've used .NET WinForms instead of Swing (or SWT) for these reasons:

      1) Out of the box the Visual Studio provides tools and support to wrap legacy COM/ActiveX controls for use in .NET host applications. This is particularly easy with respect to the IE browser control (which one of my apps makes use of). There are 3rd party tools for doing this with Java-based desktop apps but I didn't find them to be as good a tool set as what Microsoft provides.

      2) My apps take over the computer and are used in kiosk-like manner 24/7. User's can't bail out into the Windows desktop, etc. I use a number of Windows system API calls to achieve the manner of lock down required. I use Windows API calls to solve other thorny issues as well. The Java JNI is much more cumbersome to use than the interop features that Microsoft provides for C# .NET.

      3) Three years ago when I started building these distributed software systems Matisse for Java Swing development did not exist. Yet Visual Studio had a reasonable forms designer for .NET WinForms. It made building C# .NET forms applications about as easy as creating forms apps in old Visual Basic. Admittedly Matisse has very nice and very advanced constraint behavior in its forms creation and forms runtime. Yet now the .NET 2.0 WinForms designer has closed that particular gap so I have no compelling reason to switch to Matisse and Swing.

      4) Java 5 and C# 2.0 are pretty close language feature-wise with the edge going to C# 2.0. So switching to Java does not provide me with a language that has any substantial superiority. The vast open source libraries that Java has is very useful to my programming in the middle-tier yet just hasn't been an important consideration to the programming I do for the rich client apps.

      5) In order to make it easily feasible for my rich client apps to run 24/7 without becoming sluggish due to memory fragmentation, it is essential to have a runtime that has garbage collection and heap compaction. The JVM certainly provides that, but so does the .NET CLR. So again have no compelling reason to switch to Java.

      6) The messages exchanged with the Java middle-tier are text-based XML. XML is plenty easy to work with in .NET. My JMS vendor provides a .NET client for both Win32 .NET Framework and for WinCE Compact Framework. It has been entirely straightforward to build messaging software that spans between .NET and Java. So there is nothing in the communication layer or data marshalling that compel me to seek a Java solution for the client.

      7) I use log4j to do logging with my Java middle-tier software, but log4net gives me very similar capabilities for my .NET client software.

      8) The fact that the .NET runtime is a larger installable download image than the Java JRE is a non-issue. This is behind-the-firewall software and corporate admin folk take care of outfitting client machines with whatever runtime items are specified.

      The problem with Java on the desktop is that Sun has always discouraged fostering an effective Windows-specific tool environment. In their heart of hearts they don't want developers creating Java apps that only run on Windows. Alas, this position does not align with the goals of corporate developers. We have no problem conceding that Windows is the predominate platform for delivering rich client applications. We do like the advantages of Java and .NET like approach. As things stand, though, .NET is superior to Java in accommodating rich client development on the Windows platform in particular. If it were important to develop enterprise rich client apps that could run multi-platform, then Java Swing would enjoy an advantage. Yet such is really only a concern for the consumer market where Mac OS X is significantly in use. (Linux desktop is so utterly marginal that it doesn't count for anything of note in either market segment.)

      Back to top
    • Re: ah...been there done that - and its great!

      by Jonathan Allen,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Swing doesn't use native controls. This makes it look and feel differently than any other windows application. There is also a significant, as in noticable, performance cost that tends to annoy users.

      Back to top
    • Re: ah...been there done that - and its great!

      by Jonathan Allen,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Why did you choose JMS over Microsoft Message Queues or IBM Message Queue?

      Back to top
    • Re: ah...been there done that - and its great! (JMS vs MSMQ or MQSeries)

      by Roger Voss,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      JMS (at the time at least), was a superior messaging spec than what is implemented for MSMQ. Message properties for routing and filtering and topics for pub/sub (as opposed to point-to-point only). MSMQ also had a weak heterogeneous story - with Microsoft relying on other vendors to provide client support for other platforms. Most especially JMS is part of the J2EE spec and can be processed by Message-Driven-Beans (which are dirt simple to write). Microsoft never made a comparable MSMQ messaging container for ASP.NET. They've always treated messaging as a red-headed step child.

      MQSeries was IBM and am not using any IBM software stack, as in didn't want to bring in WebSphere as I preferred JBoss. Also, again a weak heterogeneous support story (wanted .NET and C/C++ clients - and even WinCE for my embedded computers).

      Ultimately I chose Tibco EMS as my JMS implementation. Tibco has had a strong track record in MOM via its Rendezvous product that is used a lot on Wall Street. EMS already had an excellent .NET client and Tibco agreed to provide a .NET Compact Framework client (which they've now had that out for quite some time and it works very well indeed on our embedded WinCE computers). Tibco also had C client binds and indeed some vendors we integrate with do indeed use C/C++.

      Refer to my article for an extensive write-up:

      Using JMS For Distributed Software Development

      MQSeries was IBM and am not using any IBM software stack, as in didn't want to bring in WebSphere as I preferred JBoss. Also, again a weak hetrogeneous support story (wanted .NET and C/C++ clients - and even WinCE for my embedded computers).

      Ultimately I chose Tibco EMS as my JMS implementation. Tibco has had a strong track record in MOM via its Rendevous product that is used a lot on Wall Street. EMS already had an excellent .NET client and Tibco agreed to provide a .NET Compact Framework client (which they've now had that out for quite some time and it works very well indeed on our embedded WinCE computers). Tibco also had C client binds and indeed some vendors we integrate with do indeed use C/C++.

      Back to top
    • Re: ah...been there done that - and its great!

      by Ted Neward,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      What's worse (although not necessarily the problem of the individual Java developer), Swing takes a huge investment in time/resources away from other projects at Sun as they try to make the Windows L&F match precisely what Microsoft releases in each successive Windows release.

      Back to top
    • Re: ah...been there done that - and its great! (JMS vs MSMQ or MQSeries)

      by Jonathan Allen,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Thanks, that was very informative.

      Back to top
    • Re: ah...been there done that - and its great! (why Winforms vs Swing/SWT?)

      by ZedroS Schwartz,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Thanks a lot.

      I have a better understanding now.

      Regarding the issue of tighter Java/Swing/Windows integration, the main issue would be to have all the features platform independent (as required Java), which for your needs would be pretty hard to achieve.

      Back to top
    • Re: ah...been there done that - and its great! (why Winforms vs Swing/SWT?)

      by Mark Pollack,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Hi!

      I feel like Ross is reading my mind ;) I came to the same conclusion/solution as he did in many areas and in particular using messaging as the interop solution between .NET and Java. (Also using TIBCO EMS). In previous work I coded up Java Swing clients to communicate with C++ server side apps via messaging and had a positive experience.

      Just to elaborate more on the JMS part of this thread. Platform/Language interop is certainly and old story from the perspective of many MOM/EAI dealers. JMS certainly helped in the standardization process on the Java side but sadly on the .NET side there isn't a defacto set of messaging interfaces (but at least the delivery semantics are nailed down). Each vendor independently reinvents/reinterprets the JMS API in .NET/C# form. There is the open source project NMS, which is loosely associated with the ActiveMQ project, but I haven't yet tried it out.

      I think the critical part of the JMS interop approach comes down to two things, the robustness of the marshalling and keeping objects in sync between .NET/Java since there is very likely some form of data binding is going on to marshal the message payload to a higher level representation. The approach I've used is to write business object in Java and then use the Java Language Conversion assistant to get a .NET version - automated via nant. The JMS marshaller works via reflection to serialize the object into nested map messages. This works very well from my experience. I'm curious if anyone has tried 'plain-ol' XML marshalling?

      Just a heads up for those who want to try this out in practice, I'll be committing the Spring.NET equivalent of the Spring.Java messaging infrastructure this week and soon after the reflection based marshaller. Just a blatent plug here...this is going to be the topic of a talk I?m giving at the next Spring conference, The Spring Experience, this December.

      Later!
      Mark

      p.s. One big thing I've seen regarding the .NET/Java decision on the client side is simply the 'culture' of the shop. Sociology and politics play just as important a role, as always, and I'm believe you can go either way in most cases and have happy users.

      Back to top
    • XML data duck typing

      by Roger Voss,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      One of the most paramount concerns in working with enterprise distributed software systems is the issue of tight coupling between nodes. This particular issue is one reason I prefer messaging vs invoking methods on a remote interface. Interface binding leads to very tight coupling. Tight coupling leads to difficulties in attempting to evolve a distributed system over time. In practice it is seldom feasible to rev tightly coupled nodes in lock step with one another. And the practice of versioning interfaces eventually becomes too burdensome if attempted pervasively.

      When messaging is applied with certain tactics it can bring about some significant relief on this front.

      Now as I was first starting out with my JMS distributed system development, I was conveying relatively complex XML documents around. These were being described in XSD and then tools like JAXB for Java and XsdObjectGen for .NET were used to generate suitable marshaling code. The documents could then be marshaled into .NET or Java object graphs with ease. This works pretty well (though Ted Neward can speak to some significant limitations and caveats) and the nature of XML Schema, as described by XSD, makes it possible to evolve document schema over time while not disrupting existing code that binds intimately to the resulting object graphs. (Yet one may sometimes still need to regenerate the code when the XSD changes which can require updating deployed code.)

      However, I eventually drifted away from this practice and now use an approach that I dub XML data duck typing - a play on the term duck typing that Dave Thomas is well known for using in his Ruby talks.

      Basically I was finding that processing nodes tended to have interest in subset information as gleaned from XML documents. This was just a natural evolutionary outcome of organic expansion/enhancement of the distributed software systems. Indeed it was very advantageous to encourage this tendency (a single message could have multiple nuances of effect based on what node processes it).

      So I now write components such that they just use XPath to glean the information that they care about from XML documents. I have a technique and a few helper methods that make this a very easy and systematic approach. The upshot of this, though, is that a given node in the distributed system could care less how radically an XML document is evolving over time so long as the info it cares about can continue to be successfully gleaned. If it looks like a duck and quacks like a duck then...

      Dropping the code generation tools and just going with XPath-based XML data duck typing has been a breath of fresh air as it breathed a new level of loose coupling into the distributed systems.

      BTW, Ted Neward is all over this entire subject matter in a talk he is giving at developer conferences that he dubs XML Services. You can catch him speaking on this at both Java and .NET conferences.

      Also, on the subject of data-driven communication vs behavior-driven communication I refer folks to Ted's book:

      Effective Enterprise Java
      Addison-Wesley Professional
      Author: Ted Neward

      For a quick taste can take a look at my PowerPoint slide show, where I reference and embellish several items from Ted's book:

      Data-Driven Communication vs. Behavior-Driven Communication

      Back to top
    • Re: XML data duck typing

      by Mark Pollack,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Hi,

      First off sorry to quote your name wrong.... I actually tried to correct it but I couldn't post to my own reply and re-replying posted in the wrong order it seems.

      Anyway, it is very interesting to hear about your experience with xpath/xsd and jms transports. What I would like to know is now that you dropped the xsd based code generation tools what data structure is exposed to the business logic, is it the xml fragment that you selected via XPath? Do you bind to any object at that point? At what point does it look more oop like?

      Our project didn't have much of a need for picking out a subset of the data to process but did have a big need to be able to quickly determine if a particular message was of interest. As such the project 'jamsel' (jamsel.sourceforge.net/) was born. This lets you use the sql subset suppoted by the jms spec used on the property headers but can be applied to the contents of any data structure, in this case a map message. This doesn't pick out the nested map-message node of interest, but has served our needs well when we started, also ~3 years ago. We don't have a hardcore EAI application, mostly client server with some other well defined integration points. In a more EAI/distributed environment I think the XML route is preferable but a little more tedious when you are really interested in sending objects around as xsd isn't an oo environment (which was our case) XPath is clearly a more standard choice for selection of nodes than our home-brewed approach.

      In either case you have a self decribing data structure (nested map messages/XML) that is pretty easy to navigate and find out the subset of what interests you. Javadoc of an particular business object is particularly nice if there is a tech savvy business user that wants to review what is being sent around, but I never had much call for that.

      As you and Ted rightfully point out, this is a great approach in distributed systems. TIBCO etc, and other messaging/EAI vendors have been promoting that party line for a long time but for whatever reason it never seems to reach a critical mass of popularity, maybe that is gonna change with Ted and others talking about it more.

      Mark

      Back to top
    • Re: XML data duck typing

      by Roger Voss,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      What I would like to know is now that you dropped the xsd based code generation tools what data structure is exposed to the business logic, is it the xml fragment that you selected via XPath? Do you bind to any object at that point? At what point does it look more OOP-like?

      Well, XPath queries can be very surgically precise in specifying what is gleaned, so typically am pulling out scalar values - and sometimes a list that can be iterated. These extracted data are mapped into an appropriately defined Java class (or classes).

      I use Spring Framework to create my Message-Driven-Beans, where I derive my primary MDB class (which implements the MessageListener interface) from Spring's AbstractMessageDrivenBean class. Doing this enables the ability to call getBean() as an instance method, which can then be used to instantiate POJO beans ala Spring's dependency injection approach (including injecting dependencies from JNDI). So my MDB classes will have a very modest implementation of onMessage() that just calls subsidiary POJO beans to do everything. The various POJO beans are what are made subject to unit test and also thereby easily debugged under my IDE.

      In this snippet of code, the very first thing done is data is gleaned from the received XML message into an RtlsInfo object (RTLS - Real-Time Location Service). That Java object is then processed in various fashion by other POJO beans. (For this particular message the MDB is only transactional against the distributed cache - in other cases, though, the MDB's onMessage() might be declared transactional so that the message could be rolled back into the queue in the event of failure.)


      /**
       * The MDB entry point for processing a received JMS message.

       *
       * Calls a method to parse message body and extract the relevant
       * parameter values and then publishes a suitable feedback message.
       */
      public void onMessage(Message msg) {
          if (log.isTraceEnabled())
              log.trace(format(">> %s.%s():%n%s",clsName,"onMessage",msg));
          try {
              if (!(msg instanceof TextMessage)) {
                  log.warn(format(rsrc.getString("txtmsg.required"),msg));
                  return;
              }
              final TextMessage txtMsg = (TextMessage) msg;
              
              final RtlsInfo info = rtlsGleanInfo.gleanInfo(builder.get(),txtMsg.getText());

              final UserTransaction tx = getMessageDrivenContext().getUserTransaction();
              if (rtlsFeedbackCheckCache.checkCacheForSending(info,tx)) {
                  final String feedback = rtlsPrepareFeedback.prepareFeedback(info);

                  txtMsg.clearProperties();
                  txtMsg.clearBody();
                  txtMsg.setText(feedback);
                  rtlsPublishFeedback.publishFeedback(txtMsg);
              }
          } catch(Exception e) {
      //      getMessageDrivenContext().setRollbackOnly();
              log.error(rsrc.getString("msg.processing.exception"),e);
          }
      }

      As you and Ted rightfully point out, this is a great approach in distributed systems. TIBCO etc, and other messaging/EAI vendors have been promoting that party line for a long time but for whatever reason it never seems to reach a critical mass of popularity, maybe that is gonna change with Ted and others talking about it more.

      Mark

      In my distributed architecture, there isn't really much OOP-think that goes on. Is mostly topology, data flow, event flow, with a lot of emphasis on filtering, routing, bridging, and transformation. OOP is pretty much just relegated to the internal design of distributed components.

      I've been programming in OOP since 1986, when I was using MPW Object Pascal on the Macintosh. From that I went to working on the C++ application framework that was used to make PageMaker portable between Mac and Windows. I've been doing distributed stuff off and on since 1994.

      I only learned to jettison OOP in respect to my distributed architecture at the onset of my current systems (which were initiated about three years ago). So it took me a while to lay down the OOP-think hammer.

      Back to top
    • Follow-up on TIBCO Enterprise Messaging Service

      by Jonathan Allen,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      www.infoq.com/news/TIBCO-EMS

      Back to top
    • Java vs .Net

      by Marc Adler,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      We have been having the same issues in the big Investment Bank that I work for. I have blogged a bit about this at magmasystems.blogspot.com. Some of the comments may be related to capital markets. I would be interested to find out what people at similar IBs have gone through to get .Net adopted.

      Back to top

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT