Microsoft Selling J++; Discontinuing Development

renaissance59 was the first to write to us with the news that Microsoft has decided to discontinue development of J++, and has signed a deal with Rational Software for them to develop J++. Interesting move, because Rational is not bound under the legal restrictions that Microsoft is when it comes to Java. I'll be keeping a close eye on what's to come.

Comments

What do we know about Rational?

[Denor]

Rational is not bound under the legal restrictions that Microsoft is when it comes to Java.

I read this paragraph, and it only vaguely disturbed me. I don't think Rational would do anything even vaguely Microsoftesque, but I had to ask myself: what do I know about Rational?

Things I know about Rational:

• They make Rational Rose, a UML design tool.
• One of the guys who works there (owns it?) invented/helped make UML
• They've got an interest in tools for Java (the non-trial version of Rational Rose can be configured for Java instead of C++)
• I've never heard of Rational trying to subvert or destroy other, smaller companies. I could be wrong here, as I'm just stating from my own failing recollection. But I think the fact that UML itself is a compendum of earlier models (authorized by the people that made them, IIRC), rather than an 'embrace and extend' helps with this impression.

Looks interesting enough, so I asked the next question: What do I know about Microsoft?

Things I know about Microsoft:

• Come on, that's too easy.

My point here is, are we dealing with a question of the devil we know versus the devil we don't, or will Rational's track record continue its trend and leave Java alone?

Re:Not a troll - Thanks to MS for breaking Java

[dmorin]

Hmmmmm, so many things with this post I have problems with.

• That closed language comes with the source code for all the class libraries. Sure, I can't hack the jVM, but I don't want to. I don't want to write a C++ optimizer either, so I don't.
• Java's not portable? I'm running code on my PalmPilot that works on my NT box. I don't even get the option to do that with Perl.
• Performance bites? Why, when the issue is Java, does everybody turn to performance...but when the issue is something like Windows being dog slow everybody just shrugs and says "Machines will get faster." The original C++ optimizers weren't very good, either. They get better. Java is faster now than it was yesterday, and it will be faster tomorrow.
• strict adherence to object orientation? Java's not really a particularly strong OO language, such as a Smalltalk. I've found it to be a nice balance in which my programmers have to put in enough structure so that I can read the fool thing, but not so much that we are taking too much time having been hindered by the structure requirements.

For the record, I work at a place where we do entirely serverside Java development on a Solaris box, serving up JSP pages. Not a Microsoft technology in the place. Could it be faster? Of course -- but I'll say that about any technology you put in front of me. I'd rather have a 733Mhz machine than a 700Mhz machine, too. That's not the point.

What M$ is all about these days: COM & XML

[Pfhreakaz0id]

XML will allow software written to Microsoft's Com object model to interact with non-Windows objects. In essence, Microsoft is replacing the DCOM RPC messaging technology with an XML/HTTP technology that allows for remote method invocation.

This is what M$ is all about. There saying everything is gonna be XML. Communication between COM objects (whether distributed or not) is gonna be through XML. They don't care about Java.

See The M$ XML development center and, more importantly The XML manifesto for a good look at what M$ is trying to accomplish. I'm not saying I agree with everything in it, but I think it explains why they are not all that interested in java. I think any programmer (whether you use M$ dev tools or not, should give it a read, as it is a good overview of component technology and where M$ think it fits in. I'll quote a few relevant pieces here:

the conclusion: Each year or so, the computer industry anoints a new technology as the "holy grail" of software development. The trade press happily bangs the drum, encouraging upper-management to hand down edicts outlining grand technology visions according to the pundit du jour. XML is bound to fall prey to this nonsense. Despite the hype, XML will not solve all of your problems. XML may or may not help you ship software faster. XML will never replace programming languages such as C++ or Java. XML will probably never replace programming technologies such as COM or Java either. XML will, however, become widely used as a way for software components to interoperate, in essence acting as a gateway between autonomous, heterogeneous systems. It is in this role that XML really excels.

other piecesDue to Windows NT's heavy orientation towards the Open Software Foundation's Distributed Computing Environment (DCE) RPC mechanism, COM leverages the DCE RPC protocol for framing and transport and uses the Network Data Representation (NDR) for parameter encoding. The Distributed COM (DCOM) protocol simply defines a handful of DCE RPC interfaces that are used for object activation, type coercion, and life cycle management. In essence, DCOM is just another DCE RPC application...

However, it is also unlikely that any of these three technologies will dominate the Internet. The network protocols used by these three technologies tend to require a non-trivial amount of run-time support to function properly. Ironically, while Microsoft and the Object Management Group (OMG) were arguing over whether the Internet would be run on DCOM or CORBA, the Hypertext Transfer Protocol (HTTP) took over as the dominant Internet protocol. Like many other successful Internet protocols, HTTP is simple, text-based, and requires very little run-time support to work properly. Additionally, many corporate firewalls block DCOM and CORBA traffic, while happily allowing HTTP packets into their (mostly) guarded networks. Finally, when you consider the amount of engineering effort dedicated to making HTTP servers (for example, Internet Information Server (IIS) and Apache) scalable, reliable and easy to administer, it becomes harder to justify not exposing your software components using HTTP technology. ...

Many view XML as a fourth component integration technology. While originally designed as a solution for adding extensions to HTML, XML is rapidly becoming the technology of choice for integrating heterogeneous component-based systems. Here's why.

XML Is Platform, Language, and Vendor Agnostic Despite the hopes of platform vendors or open-source zealots, the computing world will always be comprised of different programming languages, operating systems, and computing hardware. As XML is only a wire representation, it has no particular affinity to one operating system, programming language, or hardware architecture. As long as two systems can exchange XML messages, they can potentially interoperate despite their differences. Because XML does not mandate an API or in-memory representation, it is fairly simple to host XML in an application. There are XML parsers freely available for most (if not all) programming languages. While there are several standardized programmatic interfaces for parsing XML (for example, the W3C, DOM, and SAX), there is no mandate that one must support that API in order to interoperate with other XML-based systems

Platform Agnostic??

[roystgnr]

Despite the hopes of platform vendors or open-source zealots, the computing world will always be comprised of different programming languages, operating systems, and computing hardware.

What the fuck are they smoking? While Microsoft "Windows Everywhere" Corp. has dropped support for platform-independent Windows NT, is struggling just to put out a 64-bit NT, and puts 90% of it's development in wasted efforts to make their software as incompatible with existing standards and other vendors as possible (Win16/Win32 instead of POSIX, Windows Terminal Server instead of X, Direct3D instead of OpenGL, ActiveX/J++ instead of Java...); "open source zealots" put out multiple differing-yet-compatible Unix-like operating systems with software written in half a dozen languages, all of which strives to be portable to commercial systems and the other open source systems with little more than a recompile.