It seems like Sun's philosophy towards interoperability is that you can call any API you like so long as it's over the network. Java is a first-class ciziten when it comes to API's such as SOAP, RMI, CORBA, HTTP, X11, and so on. But try to call the same functionality via a DLL or a command-line tool and they'll make you jump through hoops.

This isn't just a Windows thing - they don't provide convenient ways to call Unix functionality like pipes and system calls either. The easiest way for two Java processes on the same machine to talk to each other is via TCP/IP!

The thing is, a network API can be just as proprietary as a non-network API. But non-network API's are the only ones they want to discourage because they might prevent an application from being moved to a Sun box.

The versioning stuff Anders talks about sounds to me like a good way to build even more complexity into systems. To me, the whole point of relying on interfaces is that I don't have to care about specific implementations of that interface, including versions. To me, the interface alone defines the identify of the object - if I change the interface, I changed the identity of object. With versioning of an interface, if I'm allowed to make major changes to an interface, and still call it the same interface, am I not making a philosophical error of a sort (with grave practical consequences)? I think this issue is really the application of Plato's Ship of Theseus problem to software design. It boils down to what defines the identity of an object: Is it its interface? Its's version plus its interface ("strong name")? Its interface plus the codebase where its classes came from?

I think that introducing versioning when defining an object's identity makes it more difficult to identify an object, and hence makes programming and system management burdensome. If object X adheres to the Food interface, but then, in version 2, I add a few methods from the Poison interface to it as well, is X now food or poison? I can't blame you if you prefer not to touch such an object, and rather create your own version (version 3), leading to more complexity.

I always thought that buggy implementations are weeded out over time by better implementations, in a Darwining fashion. If I program an object to interface X, and an implementation of X happens to be buggy, I may program around that bug, but I definitely want to know when the bug is fixed, and I'd definitely want to change my object to the corrected version.

The open source model seems to favor this method as well: If the source to a critical implementation is available, others relying on that implementation can fix the problems, and contribute their fixes back. Or, if the source is not available, but the interface is published, others can possible create a competing, less bug-ridden implementation.

I think that Microsoft still is struggling to stay alive. They want to make sure that you can still attach your old software that uses COM/OLE to the new software that you are writing. This will keep you on their platform. Sun, on the other hand recognizes that hardware and OS 'standards' are tying us down. Microsoft thinks it's the lack of software level interoptability on a single device that is tying us down. A big difference in scale.

In the beginning, microsoft wares were designed by programmers, not by engineers. Overtime, they seemed to have employed more engineers that have started to discover what the UNIX community discovered 20 years ago, and have been capitalizing on ever since. First, it was process isolation. In the 1980's all the PC users said, "We don't need that, the programmers just need to write good code." When asked about virtual memory, you could get answers from PC users such as "I'll never need more than 16MB."
When you look at scripted systems management, that was 20 years in the comming too. We'll just have to wait to see how long it takes them to recognize that the network is the computer.

Perhaps is many cases, the answer is to replace your microsoft application with something that will scale and run on a much more stable platform. Thus, interoptability is not the answer.

JNI could be easier, perhaps, but that is not the point of interface in Java. The network is the interface point. It is the most scaleable, interface that exists between applications. With COM on a single platform, you can't add more power without buying bigger hardware.

Microsoft's unfortunate, early design decisions were based on IPC rather than RPC. So, the architecture of microsoft applications and the foundation of their APIs is exactly this differentiating factor. Thus, the mindset at microsoft is strongly focused on IPC as a connector.

Look at Excel and Access and their use of COM/OLE/ActiveX. They are designed to facilitate attaching external data to the local machine. So, you'd think that microsoft gets the concept. Each of those interfaces are at the API level, using the OLE concepts. This allows these applications to interface with anything that presents such an interface. But still they have very little simplification of that programming interface, if you don't buy the upgraded tools in VS.net. So, I am not sure why they are complaining so hard about interfacing to the world, when they still have lots of work to do.

has anyone checked out this site:

http://www.geocities.com/csharpfaq/

It suggests some problems with the features in C# that aren't in Java, e.g. delegates and structs. However wrote this site clearly doesn't like C# and likes Java, but the points are well made. Some of the new features will create problems and generally don't offer much in return, i.e. your only gain is a few less keystrokes.

The new delegate feature is an example of a few less keystrokes but gives considerably weaker type checking and less functionality than instance, inner, classes in Java. IE they are a very weak contract.

Hi,

Just wanted to spread the word about a verygood software I have found.
I have been looking for a good personal calendar making software for

ages.
This software is called WinCal, its current version is 4.4, I have used

it to
design and print large A3 sized calendars using my photos, works wonders.

You can download a free trial version from:

http://www.techsysconsultants.com.au/prod01.htm

Thanks,
Best regards
suzan

I really liked the analysis by a previous poster regarding the long-term implications of adopting RPC vs IPC.

In the latest installment of the interveiw, Andres is critical of Java's designers for being too obsessed with purity, and positions C#/CLR as a more-pragmatic approach since it allows easier interop with legacy code. His examples include only components that are MS artifacts - OLE/COM, etc.

However, Java code now represents a large fraction of all legacy code in business systems. How does .Net address interoperability with legacy Java code? Is it as easy as calling a COM object? I ask out of ignorance but my guess is no.

I have never felt that the system-independance offered by Java and its JVM were about absolute purity for its own sake. You can never escape system-level concerns, but you can abstract them away and thus reap many of the well-known benefits of software re-use, pushing your development efforts farther up the stack.

It is really lamentable that Java is not part of the CLR specs, and that the CLR is not cross-platform, since language independance is arguably as important as system independance for increasing the productivity of application developers. We should have both. A project like Mono should be a big industry-wide project. The CLR represents a good evolution of the JVM idea, irrespective of the pros and cons of c#, which is after all just another language.

Sorry to casually mix together important concepts like the CLR spec and C# as a langauge in an imprecise way, I hope my points are not to muddled by it.