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.
When Rational go a year without Microsoft buying them up. I'm not paranoid, but I'm not going to trust Microsoft's motives just like that. It would not be unbelievable for Microsoft to turn them into a subsiduary, to try and rake in the profts, whilst bypassing the legal problems.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Is it possible that MS is just trying to kill Java by ignoring it? We don't support it, so no one will use it?
It almost seems these days MS is trying to cut down and refocus and re-become the fast young lean company it was. I think the DOJ really wants to help them do that. This could just be a preemptive strike by MS to break the company up on its own terms rather than have the DOJ do it. Look what we did! Sold off business. You _don't_ need to split us up.
--
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
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
J++ has a great IDE (three cheers for intellisense, or intellicomplete or whatever the hell its called), so combining that with tight integration with Rational Rose and you could design your classes with Rose, have automatic generation of all your stub code dumped straight into your IDE, and then have really nice documentation generated for you quickly in just a few steps.
I hope they have a license for the MS implementation of javac, as it blows away most of the other implementations on an x86 platform.
DrLunch.com The site that tells you what's for lunch!
JBuilder also does this.
And, though I've not tried them, I believe that Cafe, Visual Age and the free and open NetBeans does too... That, the visual UI developer, and you don't have to succumb to the dark side...
-- What you do today will cost you a day of your life.
There's actually some very good reasons to have some extensions.
In a previous project, we had to take a client/server Java program that we had and put it on the web (no, I didn't develop the original). With the MS extensions, Java and COM and almost interchangeable. This prooved to be a great boon since we had some ASP guys on the team and we could interface the backend server to IIS through COM. The whole thing worked without a hitch.
Keep in mind that this program interfaced with some real legacy systems (10-20 years old on a mainframe) and went through many hundreds of hours of testing with hundreds of small programs that deal with the data that we produced. Rewriting from scratch simply wasn't an option.
Being religous about an issue isn't always the best thing. When you have a project thrown at you with a 2-month deadline, you have to figure out the quickest way that doesn't suck and has a good probability of working the way you want it.
Remember folks, additional options are almost always a good thing.
I cannot understand why anyone would buy into Microsoft's development tools and technologies. They have shown time and time again that they cannot design a technology that will stand the test of time, and they will happily scrap anything that doesn't suit their business strategy, no matter how many developers it leaves out in the cold.
With every release of Windows, Microsoft scraps the old APIs and introduces new ones. The new ones don't solve many problems but are gratuitously incompatible with everything else.
ActiveX on the web was going to be the wave of the future. A bunch of people bought into that. Now, ActiveX on the web is an embarrassment to MS, to the point where they have changed the name just to help people forget about it. I hope you didn't stake your future on ActiveX.
DCOM was going to be the future of MS Windows IPC, but this article mentions that MS is depreciating DCOM in favor of some XML/HTTP based system. And DCOM hasn't even been fully realized yet!
And "Visual J++" was Microsoft's solution to Java. "Get all the benefits of Java with all the power of Windows", they said. Anyone who bought into that and staked their future on WFC and all that Windows-only Java are now going to find themselves at the unemployment office.
I could go on and on. Microsoft continually demonstrates they are quite happy to give their customers -- end-users and developers alike -- the shaft. My only question is, why do people continue to not only accept this, but yell, "Thank you Sir, can I have another?"
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
and its strict adherence to object-orientation demonstrates an obvious misunderstanding of trends in language design
Excuse me, but isn't most modern design theory highly object oriented?? I've never seen a design patterns book use procedural languages, not would it make sense to. The gang of four book uses C++ and Smalltalk, but not Perl or C. Any architecture books that I've seen in the past decade and a half focuses on OOP, be it Smalltalk, C++, or what not.
Scripting and procedural programming have their place, too. It's a matter of choosing the right tool for the right job.
Sheesh...
Microsoft aren't attempting to kill Java, they're just annoyed at Sun's legal succes. If they can't win the game, then they're going to take their marbles and go home in a sulk.
This move was expected a long time ago. Soon after the lawsuit, Project COOL made it clear that M$oft internal work was going back to C++, after an all too brief dalliance with J++.
I'm a COM developer, so I'm well pissed off. C++ is a ghastly platform for COM work (you can always do everything, but development speed grinds to a halt) and VB is well, still just VB (still my main language, in terms of billed hours, but I know its limits). VJ++ was nowhere near being Java, but it was excellent as a Windows development language for stuff that VB couldn't hack.
Rational's attempt is doomed. It's never going to compete with the PureJava fraternity (Visual Cafe is probably going to be my choice) and it no longer has the tie-in to M$oft internals that made it attractive in the first place. The whole Win32 baggage of VJ++ was the only thing attractive about it in the first place, but if that's no longer a hot track to the latest new Redmond arcana, then it's just a legacy albatross.
Oh yes, and if J++ is going to be anything like as unreliably buggy as Rational's recent products, then it can join them under my desk in the same dustbin. Their UML Modeller was a lot of money out of my budget for a product that wasn't fit to ship as beta-test $10 shareware.
XML as a coding language ? Don't make me laugh... Sounds like VNU still don't know their Arse++ from their ElbowScript
Time to re-write the CV again.
s/J++/Java/
Because standard libraries can't do "write once, run anywhere." Or, more accurately, they do a subset.
Java's promise is more aptly expressed by, "write once, compile once, run anywhere."
Standard libraries, using a variation, would be best summed up as, "write once, compile everywhere, run on the platform it's compiled for".
Java made the program completely machine-neutral, relying on a middle layer VM to mediate architecture differences. Standard libraries compile into machine code, which by definition is architecture dependent. You can't take Linux binaries and run them on BeOS, or Windows, or Mac OS, whereas with Java you can take a program and run it on BeOS, Linux, Windows, or Mac OS without modification (as long as you have a platform-specific virtual machine to run it on).
A single, standard GUI library would be enormously helpful, but it would only get you marginally closer towards the "write once, run everywhere" ideal. Java may not have fufilled the promise completely, but it comes closer than standard libraries do at bridging the gap between otherwise-binary-incompatible operating systems.
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.
www.HearMySoulSpeak.com
I have found J++ extremely handy for doing server-side coding. As an IDE, I haven't seen anything that can touch it. JBuilder is a big, slow piece of crap. I gave up in Visual Cafe after 2.5 wouldn't stay up for more than an hour. It was very responsive, the project management was a little difficult to adjust to, but I find it to be far easier to work with, and the drop-down auto-completion works very well (much nicer than Borland's). Also, they automatically parse Javadoc comments to give you context-sensitive help.
I have never had to recompile any J++-generated code in order to get it to run on a non-Microsoft VM (Sun's and IBM's on Solaris, Linux, and Windows).
If they had just supported pure Java GUI's in their RAD stuff, they might have dominated the market.. too bad they had to put preservation of the monopoly above the desire to make a good tool.
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
DO NOT DISTURB THE SE
I was merely being simplistic.
Had I added all the caveats, such as the myriad number of unsupported platforms, or that each individual VM has problems that either require a program to be specially tailored to that VM or to have workarounds for all the major types embedded into it, or what-have-you, my post would have been four pages long.
Addressing specific points:
* Java is indeed "machine neutral," given a perfect VM. Unfortunately, no such VM has been created. Many of the problems you'll find with Java tend to be a result of the VM. A VM on Windows will not necessarily run the same program as it will on a Mac, because the implementation of the VM specs is different or because the operating system isn't quite able to do what the Java specs require. That's not a fault of the Java language, but a fault of the implementors and/or the platform's inability to conform to what Java requires.
* As for cross-platform, Sun never said they were going to *support* every platform, only that if a VM existed on another platform that Java would run on it. That's why they released the VM specifications, so that others could develop VMs for other platforms. While some platforms have been "blessed" with official ports (such as Windows, Solaris, and BeOS, and even Linux was promised an official one, in addition to Blackdown's efforts), others have to rely on non-Sun efforts.
Or could it simply be that Java isn't suited for word processing or spreadsheets?
You're trying to pidgeon-hole Java into the role of desktop software. That's not where Java's home is. Java's home is on the back-end, in the server room of enterprise industry.
From someone coming from a C, C++, VB, and Perl background, I will tell you that java is fantastic because it has a comprehensive set of libraries (network, gui, encryption, database, web) that is standard across all platforms. And I think this is the reason it is successful and will just become more successful. All that is left is to make sure that java is supported on EVERY platform equally well. My thinking is that a OS shouldn't even ship until there is a fully functioning JRE for it.
If you want to see the power of java servlets, check out my site, a fully functioning multi-player blackjack game that can support a 1000 simultaneous users. I wrote it in a week. Try that with any other language!
By the way, I know you could do it in Perl; I love Perl, but java servlets are just so much more efficient and doesn't hog as much memory. Also, my code is neatly organized into sensible objects. That just never seems to happen with my Perl code.
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.
bullshit
.. I don't want to start a flaming war over Java performance (I'm sure somebody else already mentioned this topic and ignored all previous postings on this topic) but I'll just simply state that yes C++ is faster and no I don't care about that.
Just because you can't do a rm -rf / doesn't mean you're safe, for most users a rm -rf ~/* is bad enough.
Security is not entirely an OS responsibility. The main reason why there are no activeX viruses for Unix is because on Unix there's no such thing as a downloadable activeX component. Not providing certain functionality indeed is a form of security but not a very elegant one.
Java provides its own platform and cannot count on OS level services (though it can use them if they are present). Security is something that was done very nicely in Java.
C++ is a rather limited language from a OO perspective. It provides a lot of poorly implemented OO features, most of which were done a lot better in Java. The only real advantage C++ has over Java is performance and being close to the hardware. The disadvantages list is a lot longer: longer code, crappy memory&thread management, no security features,
Jilles
The real reason MS killed their Java products is because Sun succesfully prevented them from making it an MS specific language. When they realized that, they realized that they were competing against their own stuff (activeX, VB, Windows). So killing J++ probably was a healthy business decision from their perspective. After all what have they to gain from supporting a 100% cross platform language?
Unfortunately they are not able to innovate. VB still is based upon a crappy language called Basic. MS' first product was a basic compiler (they did not invent the language). All they did from then was add features to it that they saw in other, more promising languages. They added subroutines and even some OO like stuff but it is still Basic, a crappy scripting language.
Jilles