And consider all the lightweight containers that are moving into that middle ground. For example Spring with hibernate, OpenJMS, Quartz, and a mass of open source options is very simple to use (once you've sorted out all your options) without the J2EE baggage. And using Eclipse to pump out code greatly reduces the code to deployment cycle, as fast as with any scripting language.
For the majority of enterprise projects I've worked on, we wouldn't event consider a platform that didn't perform Two Phase Commits (MySQL) nor supported distributed transactions. This stuff still has a long way to go before it's to be taken seriously.
Agreed, in fact strict adherence to metaphor is well known in UI design to create needless limitations that exist only in real-world devices. It is a design flaw, which the gnome crowd are not the first to be guilty of.
An old example but still a good lesson in going too far down metaphor road.
You said it; Java's main angle is Enterprise software so you can't even begin comparing it to Python and Perl in a business sense. It's a completely different ballpark, with corporate politics and business and marketing people calling the shots.
In Perl's open source world, it makes no sense to damage the Perl platform for personal gain, since the real enemy is big-bad-corporation-x. But the high flyers in the 'enterprise market', when not engaging in corporate sex will unhesitatingly sell-out said partner if they can make a buck.
In such a climate, it's important to keep hold of your assets, and to watch your back. Sun and IBM have had some very public spats throughout Java's history, and it would be interesting to see what IBM would have done with Java, given the chance. And another company... in fact, let's not go there.
I agree with the original poster in that Sun has done the right thing, and held the right amount of control while making the technology available for everyone. The issue is more than just technical; Java is an important branding for Sun (observe the Java desktop that has very little to do with the Java platform). It's important ip-mindshare (if such a term exists). It gives them credibility as a company. Yes it's hard to see how they've directly benefited from Java as a technology but that's old news.
In the Java world Sun have proven themselves to be the good guys, with the majority of Java developers (that I know of) fine with the present situation. It's a fact of the enterprise market that there's a good helping of politics that drives everything. To say Sun has bungled Java is ridiculous. So it didn't take off in the desktop market? That doesn't even come into play with what we're talking about, plus Sun has been working hard on this issue with Tiger.
As for dot net, far from being afraid, most Java developers are excited about the new technology and looking for opportunities to learn it. For most serious developers the mentality is that each new technology has its advantages and trade offs, and learning more serves to increase your problem-solving arsenal. And to say dot net has better tools is just mindlessly parroting microsoft's fud track. It's just not true once you peel back the glossy exterior. But this is getting off-topic.
Licensing issues with open source software will always be a problem, but that's because you're mixing technologies that are designed for different markets and purposes. Will Java become open-source? I'd say one day probably, but it's still a way off, most likely when it has served its purpose in the corporate arena. And hopefully, that will serve to breathe new life into the technology.
Ok some research, from MSDN. Note that this applies to OutLook 98 although OutLook2k is the same. Note also that the virus does not contain an embedded script but an attachment so this doesn't even really apply. --- OL98: Item Using VBScript Cannot Be Displayed In Preview Pane ID: Q231989 The information in this article applies to: Microsoft Outlook 98 SYMPTOMS You select an item in a folder, and the preview pane displays the following message: Items with embedded script cannot be displayed in the preview pane. CAUSE The Outlook preview pane does not support displaying items that contain "active content." However, the behavior is different depending on the type of item you are using. MORE INFORMATION If the item is a mail message or post, it cannot be previewed if the item is based on a custom form that uses Visual Basic Scripting Edition (VBScript) in any way. If the item is something other than a mail message or post, it will display in the preview pane if it is based on a published form. However, it cannot be previewed if the item -- at any point in time -- contained VBScript that was directly stored within the item. Once an item contains programming code, Outlook sets a flag in the item indicating that it contains active content. Once this flag has been set, it cannot be reset. If you delete the VBScript, or programmatically change the message class so that the item will once again used a published form, the contents of the item will still not be viewable in the preview pane. VBScript code can be stored in the item if the form designer specified saving the form definition with the item, or if the item somehow used a one-off form....
And consider all the lightweight containers that are moving into that middle ground. For example Spring with hibernate, OpenJMS, Quartz, and a mass of open source options is very simple to use (once you've sorted out all your options) without the J2EE baggage. And using Eclipse to pump out code greatly reduces the code to deployment cycle, as fast as with any scripting language.
Heh, make that 2PC. But while we're onto TPC figures...
For the majority of enterprise projects I've worked on, we wouldn't event consider a platform that didn't perform Two Phase Commits (MySQL) nor supported distributed transactions. This stuff still has a long way to go before it's to be taken seriously.
An old example but still a good lesson in going too far down metaphor road.
You said it; Java's main angle is Enterprise software so you can't even begin comparing it to Python and Perl in a business sense. It's a completely different ballpark, with corporate politics and business and marketing people calling the shots.
In Perl's open source world, it makes no sense to damage the Perl platform for personal gain, since the real enemy is big-bad-corporation-x. But the high flyers in the 'enterprise market', when not engaging in corporate sex will unhesitatingly sell-out said partner if they can make a buck.
In such a climate, it's important to keep hold of your assets, and to watch your back. Sun and IBM have had some very public spats throughout Java's history, and it would be interesting to see what IBM would have done with Java, given the chance. And another company... in fact, let's not go there.
I agree with the original poster in that Sun has done the right thing, and held the right amount of control while making the technology available for everyone. The issue is more than just technical; Java is an important branding for Sun (observe the Java desktop that has very little to do with the Java platform). It's important ip-mindshare (if such a term exists). It gives them credibility as a company. Yes it's hard to see how they've directly benefited from Java as a technology but that's old news.
In the Java world Sun have proven themselves to be the good guys, with the majority of Java developers (that I know of) fine with the present situation. It's a fact of the enterprise market that there's a good helping of politics that drives everything. To say Sun has bungled Java is ridiculous. So it didn't take off in the desktop market? That doesn't even come into play with what we're talking about, plus Sun has been working hard on this issue with Tiger.
As for dot net, far from being afraid, most Java developers are excited about the new technology and looking for opportunities to learn it. For most serious developers the mentality is that each new technology has its advantages and trade offs, and learning more serves to increase your problem-solving arsenal. And to say dot net has better tools is just mindlessly parroting microsoft's fud track. It's just not true once you peel back the glossy exterior. But this is getting off-topic.
Licensing issues with open source software will always be a problem, but that's because you're mixing technologies that are designed for different markets and purposes. Will Java become open-source? I'd say one day probably, but it's still a way off, most likely when it has served its purpose in the corporate arena. And hopefully, that will serve to breathe new life into the technology.
Ok some research, from MSDN. Note that this applies to OutLook 98 although OutLook2k is the same. Note also that the virus does not contain an embedded script but an attachment so this doesn't even really apply. --- OL98: Item Using VBScript Cannot Be Displayed In Preview Pane ID: Q231989 The information in this article applies to: Microsoft Outlook 98 SYMPTOMS You select an item in a folder, and the preview pane displays the following message: Items with embedded script cannot be displayed in the preview pane. CAUSE The Outlook preview pane does not support displaying items that contain "active content." However, the behavior is different depending on the type of item you are using. MORE INFORMATION If the item is a mail message or post, it cannot be previewed if the item is based on a custom form that uses Visual Basic Scripting Edition (VBScript) in any way. If the item is something other than a mail message or post, it will display in the preview pane if it is based on a published form. However, it cannot be previewed if the item -- at any point in time -- contained VBScript that was directly stored within the item. Once an item contains programming code, Outlook sets a flag in the item indicating that it contains active content. Once this flag has been set, it cannot be reset. If you delete the VBScript, or programmatically change the message class so that the item will once again used a published form, the contents of the item will still not be viewable in the preview pane. VBScript code can be stored in the item if the form designer specified saving the form definition with the item, or if the item somehow used a one-off form. ...