I think Sun's problem was that they didn't have a coherent business strategy for Java but instead managed it day-by-day as a anti-Microsoft strategy.
They really had two viable alternatives:
They could have kept firm control of Java by not licensing it and thus prevent MS or anyone else from optimizing it on a particular platform. To be viable on Windows, they would have had to develop the kind of GUI-based tools that Windows developers are used to and Unix folks traditionally hate. Only now, many years later, they understand this.
On the other hand, the fact that they licensed Java to MS who embraced (and yes, extended) it, meant that Java was taken much more seriously as a development language than it might have been if MS ignored it. They could also avoid having to develop the GUI-based tools they didn't believe in.
The problem came from trying to mix the strategies in order to provide maximum pain for MS. They let MS optimize Java for Windows and then turned around and sued them for it. The result was that MS dropped support for J++ and since Sun never promoted a competitive Java environment on Windows, they basically discouraged Windows developers from writing in Java.
I believe at this point that the high-growth days of Java are behind us and I don't see any action Sun can take that will bring those days back.
If this tailoring is of the same sort that companies already do with closed source applications (in other words writing custom apps), no additional jobs are being created.
If on the other hand, this tailoring is actually modifying open source OS's, tools, etc, it seems to me that the amount of work is actually increasing and the cost to a small business is going up. I don't see small companies shelling out this extra money in the long run.
On the other hand, if small companies expect to pay their staff less because the orginal software was free, then it could work.
What do you base this conclusion on? Although it is plausible that more people audit Linux code than say Solaris code, there really is no proof of that (unless you are aware of some). I have a library down the street with access to thousands of books. That doesn't mean I'm going to read them all or critique them.
Well, as a former Xerox employee I feel bad that Xerox was not able to benefit from a lot of their ideas, but they lacked the vision to implement those ideas outside of their traditional business area.
Their duty is to protect the interest of shareholders. If that is best achieved by using a different legal strategy in the US than in Europe, than that's what they are obligated to do. These are legal matters, not a formal debate.
This reminds me of the political cartoon that showed Richard Nixon nailing himself to the cross. If Windows.com gets bled dry, it will be from a self-inflected wound.
The only thing you didn't consider was Lindow.com's claim (at least in the beginning) that it could run Windows applications. So it's not just an issue of similiar names, it's using a similiar name for a product that purports to be a replacement.
This is not like having two kinds of facial tissues. Making a Windows-compatible system is a highly technical and specific undertaking. So the court should consider whether Lindows.com's intent was to confuse the consumer as well as the plausibility of that confusion.
They are not trying to "extend" their trademark. They are trying to defend the trademark they already have. They won't go after X Windows because X Windows has never purported to be a MS Windows replacement.
I suspect Lindows will eventually go out of business because they're more interested in a pissing contest with MS than with growing their business. If they changed their name, it wouldn't decrease their sales (assuming they have any) and they could save a ton of legal fees.
Lucas made a big mistake in waiting to release this. He would have made a lot more money if he had released it before he deluted the franchise with Episode's I and II.
Despite the fact that I have answered your question: "Why was yet another COM language needed?" you now consider the question irrelevent because it conflicts with your unwavering belief that J++ is entirely about fragmenting Java. It's clear that no evidence will convince you otherwise, so I'll give up.
"I just wanted to point out that I think it's a great leap of faith for IBM to let this out from underneath their wing."
Translation: They couldn't figure out how to make money on it.
"Remarkable, some people at IBM seem to get OSS on a strategic level, not just superficially."
That must be a tiny minority. Believe it when they start releasing source for products that represent an independent source of revenue (i.e. products that don't lead to hardware sales).
You have the right to have the opinion that smart pointers are not a kludge, but the fact remains that the J++ JVM lets programmers treat COM objects as first class objects without application-level wrappers. If J++ was merely designed to prevent cross-platform development, there would be no reason to add this capability to J++.
"The JVM for Windows is fully dependent on the Windows API..."
Perhaps the problem was that you didn't say what you were thinking in your first post.
"Yes, Microsoft's changes to the VM were both sneaky and effective"
But I was responding to your claim that C# was the Java killer. I don't agree with your conclusions about why Java failed on the desktop, but if you agree that it did, than there's no need for MS to produce C# to kill something that is already dead.
I wouldn't call VB or VC++ "COM aware", more like COM compatible.
There are a number of technical reasons why it's easier to perform COM programming using J++. The general idea is that MS's JVM makes COM objects look like Java objects. The J++ programmer never has to call Release() or QueryInterface() the way C++ programmers have to.
MS took the opportunity to make J++ the best language to use for COM programming. They also knew that programmers were interested in the language and so they decided to support it.
If you recall, Java applications in those days were much slower than they are now so J++ gave the programmer the option to make their app more efficient by allowing more direct calls to the API than standard Java allowed. The tradeoff was in portability. This tradeoff was no secret.
The net effect was that Java applications looked more appropriate and ran faster on Windows than "pure Java" apps. You could argue that J++ actually improved Java's image at that time.
Of course you're creating a hypothetical scenario without evidence to support your position. One could just as easily speculate that the existence of the clumsy virus has no effect whatsoever on protecting against the more subtle one.
So the choice could be between having just the subtle viruses or having both the clumsy and the subtle. I'd prefer the former to the latter.
You're not serious. Sun got the press to report that Java was a new computer language that allowed, for the first time, programs to run on ANY computer. That's the biggest marketing coup in the history of computers.
"If you are a Windows programmer looking to create or move your stand-alone database applications away from Microsoft-specific tools such as Visual Basic, Visual C++, Access or SQL Server, MySQL: Building User Interfaces is written just for you."
Very few Windows applications are written in 'C' these days so converting an existing application to use MySQL would be pretty painful. You should have a better reason to port your code then simply avoiding MS tools.
Perhaps the book is better suited for developers who wish to switch to Linux for future development.
Sounds like a great idea for the "Lusers"! Your so-called Luser internet would be totally without viruses because none of the users would be able to write one. Meanwhile, the hackers would be forced to target the UnixNet.
I think Sun's problem was that they didn't have a coherent business strategy for Java but instead managed it day-by-day as a anti-Microsoft strategy.
They really had two viable alternatives:
They could have kept firm control of Java by not licensing it and thus prevent MS or anyone else from optimizing it on a particular platform. To be viable on Windows, they would have had to develop the kind of GUI-based tools that Windows developers are used to and Unix folks traditionally hate. Only now, many years later, they understand this.
On the other hand, the fact that they licensed Java to MS who embraced (and yes, extended) it, meant that Java was taken much more seriously as a development language than it might have been if MS ignored it. They could also avoid having to develop the GUI-based tools they didn't believe in.
The problem came from trying to mix the strategies in order to provide maximum pain for MS. They let MS optimize Java for Windows and then turned around and sued them for it. The result was that MS dropped support for J++ and since Sun never promoted a competitive Java environment on Windows, they basically discouraged Windows developers from writing in Java.
I believe at this point that the high-growth days of Java are behind us and I don't see any action Sun can take that will bring those days back.
If this tailoring is of the same sort that companies already do with closed source applications (in other words writing custom apps), no additional jobs are being created.
If on the other hand, this tailoring is actually modifying open source OS's, tools, etc, it seems to me that the amount of work is actually increasing and the cost to a small business is going up. I don't see small companies shelling out this extra money in the long run.
On the other hand, if small companies expect to pay their staff less because the orginal software was free, then it could work.
"The command prompt to DOS was as cryptic as *nix".
To see the contents of a directory:
DOS: dir
Unix: ls
To display the contents of a file to the screen:
DOS: type
Unix: cat
Sorry, but whatever limitations DOS may have, it's commands are clearly less cryptic than Unix's.
If your response has a point to it, I fail to see it.
What do you base this conclusion on? Although it is plausible that more people audit Linux code than say Solaris code, there really is no proof of that (unless you are aware of some). I have a library down the street with access to thousands of books. That doesn't mean I'm going to read them all or critique them.
How's that for a Freudian slip? I should have said "Lindows.com" not "Windows.com".
Well, as a former Xerox employee I feel bad that Xerox was not able to benefit from a lot of their ideas, but they lacked the vision to implement those ideas outside of their traditional business area.
Their duty is to protect the interest of shareholders. If that is best achieved by using a different legal strategy in the US than in Europe, than that's what they are obligated to do. These are legal matters, not a formal debate.
This reminds me of the political cartoon that showed Richard Nixon nailing himself to the cross. If Windows.com gets bled dry, it will be from a self-inflected wound.
The only thing you didn't consider was Lindow.com's claim (at least in the beginning) that it could run Windows applications. So it's not just an issue of similiar names, it's using a similiar name for a product that purports to be a replacement.
This is not like having two kinds of facial tissues. Making a Windows-compatible system is a highly technical and specific undertaking. So the court should consider whether Lindows.com's intent was to confuse the consumer as well as the plausibility of that confusion.
They are not trying to "extend" their trademark. They are trying to defend the trademark they already have. They won't go after X Windows because X Windows has never purported to be a MS Windows replacement.
I suspect Lindows will eventually go out of business because they're more interested in a pissing contest with MS than with growing their business. If they changed their name, it wouldn't decrease their sales (assuming they have any) and they could save a ton of legal fees.
Tills, yes, but it takes coordination to flip burgers. Let's face it. If it weren't for computers we'd starve.
Lucas made a big mistake in waiting to release this. He would have made a lot more money if he had released it before he deluted the franchise with Episode's I and II.
Despite the fact that I have answered your question: "Why was yet another COM language needed?" you now consider the question irrelevent because it conflicts with your unwavering belief that J++ is entirely about fragmenting Java. It's clear that no evidence will convince you otherwise, so I'll give up.
"I just wanted to point out that I think it's a great leap of faith for IBM to let this out from underneath their wing."
Translation: They couldn't figure out how to make money on it.
"Remarkable, some people at IBM seem to get OSS on a strategic level, not just superficially."
That must be a tiny minority. Believe it when they start releasing source for products that represent an independent source of revenue (i.e. products that don't lead to hardware sales).
You have the right to have the opinion that smart pointers are not a kludge, but the fact remains that the J++ JVM lets programmers treat COM objects as first class objects without application-level wrappers. If J++ was merely designed to prevent cross-platform development, there would be no reason to add this capability to J++.
"The JVM for Windows is fully dependent on the Windows API ..."
Perhaps the problem was that you didn't say what you were thinking in your first post.
"Yes, Microsoft's changes to the VM were both sneaky and effective"
But I was responding to your claim that C# was the Java killer. I don't agree with your conclusions about why Java failed on the desktop, but if you agree that it did, than there's no need for MS to produce C# to kill something that is already dead.
I wouldn't call VB or VC++ "COM aware", more like COM compatible.
There are a number of technical reasons why it's easier to perform COM programming using J++. The general idea is that MS's JVM makes COM objects look like Java objects. The J++ programmer never has to call Release() or QueryInterface() the way C++ programmers have to.
MS took the opportunity to make J++ the best language to use for COM programming. They also knew that programmers were interested in the language and so they decided to support it.
If you recall, Java applications in those days were much slower than they are now so J++ gave the programmer the option to make their app more efficient by allowing more direct calls to the API than standard Java allowed. The tradeoff was in portability. This tradeoff was no secret.
The net effect was that Java applications looked more appropriate and ran faster on Windows than "pure Java" apps. You could argue that J++ actually improved Java's image at that time.
"Java allowed developers to write software for Windows that was not dependent on Windows APIs"
Excuse me? Java applications that run under Windows are fully dependent on the Windows API. What do you think the JVM talks to - the ROM BIOS?
As far as the threat posed by Java, Sun had already failed on the Windows desktop before C# and the CLR were released.
Of course you're creating a hypothetical scenario without evidence to support your position. One could just as easily speculate that the existence of the clumsy virus has no effect whatsoever on protecting against the more subtle one.
So the choice could be between having just the subtle viruses or having both the clumsy and the subtle. I'd prefer the former to the latter.
Slashdot doesn't even trust us to judge posts without moderation, so I guess rating video games isn't any worse.
You're not serious. Sun got the press to report that Java was a new computer language that allowed, for the first time, programs to run on ANY computer. That's the biggest marketing coup in the history of computers.
"If you are a Windows programmer looking to create or move your stand-alone database applications away from Microsoft-specific tools such as Visual Basic, Visual C++, Access or SQL Server, MySQL: Building User Interfaces is written just for you."
Very few Windows applications are written in 'C' these days so converting an existing application to use MySQL would be pretty painful. You should have a better reason to port your code then simply avoiding MS tools.
Perhaps the book is better suited for developers who wish to switch to Linux for future development.
Sounds like a great idea for the "Lusers"! Your so-called Luser internet would be totally without viruses because none of the users would be able to write one. Meanwhile, the hackers would be forced to target the UnixNet.