Slashdot Mirror


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.

2 of 420 comments (clear)

  1. What do we know about Rational? by Denor · · Score: 5
    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?
    --
    -Denor
  2. What M$ is all about these days: COM & XML by Pfhreakaz0id · · Score: 5
    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