Still waiting for true .NET – JAVA interoperability

Still waiting for true interoperability

One of the big things presented in JavaOne was .NET-Java interoperability. The notion of language interoperability can be understood and implemented in several different ways.

Sun and Microsoft introduced interoperability by means of web-services (WS). It seems that short of a cure for cancer, web-services is the answer to everything. While in some conditions WS is a good way for applications (written in different language or the same) to interact, this seems like a cumbersome way for simple (POJO) situations especially when the two applications are on the same machine.

Our open-source project, MantaRay, also tries to achieve language interoperability. We provide our JMS offering in Java and .NET, thus you can send a message in C# and receive it in java and vice versa. We keep the protocol layer unified to provide our language interoperability, while this might be simpler or even faster than WS it basically suffers from the same shortcomings.

Another solution presented in the JavaOne pavilion was of shared memory between .NET and Java. This is an interesting approach for interoperability within the same machine. But it lacks an event driven mechanism and method invocation, you need to write your own code that checks if the shared variable has changed. So this is, in effect, a very thin offering.

And there is JNI for Java-C++ interoperability. In the alumni “fire side chat” the guys from SUN admitted, when asked why JNI invocation takes so long, that JNI is sometimes slow and that Java itself used “dirty optimizations” in order to achieve better C++ invocation speed.

There was a company that implemented a “source time/compile time” interoperability approach, you write you code in .NET and access Java libraries as you see fit. At compile time your code is converted to Java. They showed a very simple demo and I am not sure what the limitations of this solution are.

I have a dream, in my dream you write the code in any language you like and mash-up different languages. I would like to write a multi tier application, writing every tier in a different language, and not worry about interoperability.

Technology should enable things. It should be simple and efficient. Interoperability is an issue because of licensing, lack of standards, lack of good will and business competition. As developers, and consumers of technology, we must strive to be able to use the right tool for the right task, we should push for open standards and seamless interoperability. We must make sure the technology providers (Microsoft and Sun) know that is important for their business to provide this interoperability for us.

Amir Shevat
2006-05-28T07:45:38-08:00
[Amir blog and articles]

Tip: Solving the browser caching problem of AJAX applications

Browser caching is generally a good thing, why download the same image again and again while you can download it once and save it on the browser? In some cases, however, this is not a wanted behavior.

The problem:
AJAX application tends to frequently ask the server for the same URL (a stock quote, application status and so forth). The AJAX application expect a response form the server while, in fact, after the first request the browser returns the cached page and the AJAX application does not work as expected. Clearing the browser cache or setting “no cache” parameters on the page does not always work.

The solution:
Add a pseudo-random parameter to the URL the AJAX application is requesting. Doing so will fool the browser to think this is a new page that has not yet been cached.

For example, this is how I would add a pseudo parameter to a URL in JavaScript :

var url = “http://mydomain?myParameters=myValues&pseudoParam= “+new Date().getTime();

The Date().getTime(); returns a new value every millisecond (or so), the browser thinks this is a new page that has not been cached and requests the URL form the server.

Tip: how to write an XML document with JSP for AJAX applications

AJAX applications usually connect to a server side application and request data in the form of XML. When the server side is written in JSP (Java Server Pages), for example a spring-framework web application with JSP views, writing the XML response is sometimes problematic.

The problem:

When using JSP to format the data in to XML and send it to the AJAX application, the XML is not recognized as XML (empty DOM object) and the AJAX application does not function properly.

The solution:

Add this to the beginning of the JSP
<%

response.setContentType(“text/xml”);
response.setHeader(“Cache-Control”, “no-cache”);
response.setHeader(“pragma”,”no-cache”);

%>

In addition, make sure there are no spaces between this addition and the root tag of the XML in the JSP, these spaces might create the same problem.

An example of this AJAX-JSP communication can be found in the Spring-dashboard code under the examples folder in this release (files: monitorData.jsp and monitor.jsp)

Another issue you might face with AJAX is client side caching. You can read more about this and how to solve this issue in this article – Solving the browser caching problem of AJAX applications

Removing the Ant Configuration Selection in eclipse

When I updated to eclipse 3.2 I found a new irritating feature:

The problem:
The first time when selecting the Run As-> Ant build… on any of the ant tasks (targets) you have in your build.xml file, you get a window called “modify attributes and launch.”

After that any time you try to run an ant task (with or without the build…) you get an annoying “Ant Configuration Selection” window that makes the ant running process a click longer.

The solution:
From the top menu select run->External Tools-> External Tools… which will bring you to “create, manage, and run configurations” window, there delete all the pre-defined tasks under ant build (on the left bar of the window) and click “close”…
I found this workaround here: http://dev.eclipse.org/newslists/news.eclipse.platform/msg20976.html

I hope eclipse will provide a different mechanism that will work around this problem in their next release.