To support Blu-ray, Microsoft's player would have to use Java to render the Blu-ray disks user interface - interactive menus etc (current DVDs use pre-rendered MPEG menu elements with very simple control interfaces). Does Microsoft want to depend on a Java Virtual Machine for anything? Like hell they do.
HP's current "appeal" to the Blu-Ray Assoc also includes a request for Blu-Ray to support iHD, the XML based menuing definition language used by HD-DVD. The Blu-Ray Assoc (including HP!) did a side-by-side eval of iHD vs BDJ (Blue Ray Java) and they heavily favoured the BDJ solution. If iHD was adapted as an alternative (or replacement for BDJ) MS wouldn't have to use/license Java. Then they might consider supporting Blue-Ray (even though it would still hurt like hell). HP are doing Microsoft's bidding on this one, no doubt.
I imagine Sun have been on the blower to Sony & company on more than one occasion since HPs 'appeal' yesterday.
IBM are basing their future application self-healing abilities on what they call a whole branch of research they have been investing in for years called Autonomic Computing
It's not all pie in the sky either - they've already released preliminary Autonomic Computing Toolkits as part of their Emerging Technologies Toolkit. Start by looking at the Logging and Trace components, and then maybe look at the Solution Install pieces - they underpin the whole framework.
It will take a generation, or two (10-15 years) before complete IBM systems (hardware, OS, middleware, databases, applications etc) are close to autonomic - every aspect have to buy in and adapt the Autonomic Compouting framework. Given their extensive software catalog, IBM themselves will probably take 10-15 years to complete that task but they face a significantly larger hurdle convincing major 3rd party vendors (e.g. Oracle, SAP etc) to wire their products into the new autonimic services.
My guess is, in a mixed vendor (hardware/OS/application) environment, you won't see this for many, many years to come. Pure IBM shops may be able to rely on Autonomic systems within 5-10 years if they are using the latest of everything.
Yep, you're right, but as you mention, these are the 1.1.4(?) APIs and will never be updated (for legal reasons) to J2SE level APIs which is what most Java developers are using today.
That precludes automatically compiling an awful lot of Java source code - e.g. existing code which uses Swing, rmi, CORBA, sound, 3D and even newer APIs for logging, printing, crypto etc. It also closes the door to any existing J2EE API based code (e.g. JDBC 2.0 - of course EJBs and Servlets are non runners!)
The roadmap is clearly to migrate more recent code to the.NET Framework equivalents. If you take that route, you are using the Java language but not the java platform and you're locked in. If that's what people want, MS is definately the company to give it to them but they should be clear about what they are getting tied into.
Re:Initial reactions
on
J#
·
· Score: 3, Informative
"The focus seems to be on J++ developers, not Java developers. But personally, I will use J# iff:
* I have to make exactly zero changes to my Java to have it compile to both VM bytecodes and to a.NET executable. "
That won't be possible. The.NET Framework Base Class APIs available through J# are not based on the J2SE APIs although in places the object models look similiar. For example, both have a base Object class from which all other classes inherit but even the APIs on this class are different. All of the auxiliary APIs for IO, Math, Collections, Security, Reflection also differ in too many ways to describe. Perhaps they will provide tools to automate the conversion of source from one API set to the other but don't expect it to be automatic.
That's not to say that the.NET Framework is worse than the J2SE APIs or vice versa - they are just different.
All Microsoft are facilitating with J# is allowing developers who know the Java language syntax to develop.NET apps using the.NET Framework APIs. Java the platform (the JS2E APIs and VM) are not part of the deal.
Re:There's a lot more to eXtreem than pairs...
on
"Extreme" Programming
·
· Score: 1
Absolutely. We were lucky to be starting a green field project in a large 'non-extreme' engineering organization but we were given the freedom to use the extreme methodology. By the time our product had gone trough three major releases (and several point releases) in 14 months, the other engineering divisions were very interested in how we worked.
It is a very difficult switch if development needs to continue at full speed during the transition.
Pair programming practice is only one part of the XP methology - people tend to focus way to much on it's importance to XP. There are many other practices that are all equally as important
Planning - up front, and iterative
Short release cycles - small incremental builds build confidence in the build system, test rig and final kit
Simplify design - bite off the minimum amount of work for each release
Use methaphors - use a common familiar naming system for features and components whenever possible
Refactoring - refine code when necessary. A subject upon itself (check out Martin Fowlers book)
Unit testing - unit test, unit test, unit test. If you want to write the code, you write the tests first. Run the tests as often possible (whenever you change the code) With a good unit test suite, accidently introducing bugs as a result of refactoring code isn't as likely
Continuous integration - merge changes as quickly as possible, keeping everone in sync. A decent configuration management tool is essential.
On site customer - customer has direct input to requirements/priorities.
Code ownership - or rather collective ownership of code. If you see something that should be changed, you don't need to request permission. Do it.
Coding standards - required for Collective ownership to be possible. Rules are required to ease readability
Pair programming - As described already
40 hour week - if you're burnt out you'll make mistakes
The point is, XP uses *all* of the above practices - they're an interdependent matrix of practices in which each supports many others. (For example, continuous integration facilitates small releases which in turn facilitates iterative planning etc, etc.)
If you choose not to implement several of these practices then the methology starts to break down. I think this is what makes it so difficult for a lot of engineering organizations to switch to XP - there is simply an awful lot to change, a lot more than buying desks which can seat two people...
"Tested Versions:
Microsoft tested IE 5.01 and IE 5.5 to assess whether they are affected by this vulnerability. Previous versions are no longer supported and may or may not be affected by this vulnerability."
In other words the vunerability probably exists in IE 4 too but they don't care - not supported.
Also, I'd expect most Mandrake (or does that affect all Linux kits - I guess so) users to be reasonably aware of the bug you mention.
However, I wouldn't expect ordinary corporate/home IE users to habitually check Microsoft's security update centre, even if they knew such a thing existed. I'm thinking of the countless squillions of non-techie desktop users who just don't know about these issues. The dominant market share held by IE with this demographic only exasperates the problem.
I, for one, am glad I'm aware of issues like this and can avoid it (Mozilla:) - it's frustrating to think of millions of others without so much as a clue the vunerability exists...
This has to be the worst bugs turned up in IE to date - visiting a website gives them full permission to run executables on your machine. Aaarrrgghh. Why don't the Windows OS's ship with anonymous telnet and ftp daemons running by default? Save you the "edge of your seat" ride while you tippy-toe around the net in fear.
I wonder how long it will take the 5 squillion users running IE5.x to install that patch(let alone the 50 squillion running IE4.x) How quickly will coporate IT departments roll it out? Combined with Verisign accidently issuing Class 3 certs to some bloke with the common name "Microsoft Corporation" Microsoft must be just waiting for the class action suits to roll in.
I can't wait until.net comes. Think about it, I can just forget my windows passwords I keep in my head because they will be redundant
open up your data to other patforms, programming languages (not markup languages) and tiers in the enterprise.
participate and adhere to a published and accepted DTD (Schema) for the XML data you are generating.
choose the right underlying protocol. Unfortunately the prime candidate for the "ideal" protocol for tranporting XML content is causing market segmentation mainly due to the disparity of environments into which XML data is used. SOAP (XML over HTTP) is viable only for a low volume of messages or very high speed networks. XML over IIOP is more efficient but lacks standardization (what does your IDL interface look like). Then you've got other proprietary solutions like MQSeries and other budding standards like XML-RPC which are muddying the waters.
Lastly, the cost of marshalling/unmarshalling XML documents using something like the DOM API is prohibitive. I know, I know, you can get your hands dirty by using SAX directly but it is extra work and usually ends up specific to a particular XML document DTD or Schema. JDOM is a decent enough API but is Java only.
I'm not knocking XML - it a young specification with massive industry support which will hopefully give rise to mature systems. Lets keep those vendors from hijacking either the XML or vertical industry data specifications though. Otherwise you may as well use byte streams - same vendor lock-in but more efficient.
Lets drop any arguments about "The American Way (tm)" What you've got here is a representative of the largest software in the company saying that competition from volunteers is bad. Exactly who's interests is he defending? I am baffled that this is even a debatable issue?
Slashdot Mirror
To support Blu-ray, Microsoft's player would have to use Java to render the Blu-ray disks user interface - interactive menus etc (current DVDs use pre-rendered MPEG menu elements with very simple control interfaces). Does Microsoft want to depend on a Java Virtual Machine for anything? Like hell they do.
i res-a-jvm-microsoft-dont-do-jvms/)
HP's current "appeal" to the Blu-Ray Assoc also includes a request for Blu-Ray to support iHD, the XML based menuing definition language used by HD-DVD. The Blu-Ray Assoc (including HP!) did a side-by-side eval of iHD vs BDJ (Blue Ray Java) and they heavily favoured the BDJ solution. If iHD was adapted as an alternative (or replacement for BDJ) MS wouldn't have to use/license Java. Then they might consider supporting Blue-Ray (even though it would still hurt like hell). HP are doing Microsoft's bidding on this one, no doubt.
I imagine Sun have been on the blower to Sony & company on more than one occasion since HPs 'appeal' yesterday.
(blogged about this earlier -
http://www.xlml.com/aehso/2005/10/21/blu-ray-requ
IBM are basing their future application self-healing abilities on what they call a whole branch of research they have been investing in for years called Autonomic Computing
It's not all pie in the sky either - they've already released preliminary Autonomic Computing Toolkits as part of their Emerging Technologies Toolkit. Start by looking at the Logging and Trace components, and then maybe look at the Solution Install pieces - they underpin the whole framework.
It will take a generation, or two (10-15 years) before complete IBM systems (hardware, OS, middleware, databases, applications etc) are close to autonomic - every aspect have to buy in and adapt the Autonomic Compouting framework. Given their extensive software catalog, IBM themselves will probably take 10-15 years to complete that task but they face a significantly larger hurdle convincing major 3rd party vendors (e.g. Oracle, SAP etc) to wire their products into the new autonimic services.
My guess is, in a mixed vendor (hardware/OS/application) environment, you won't see this for many, many years to come. Pure IBM shops may be able to rely on Autonomic systems within 5-10 years if they are using the latest of everything.
Yep, you're right, but as you mention, these are the 1.1.4(?) APIs and will never be updated (for legal reasons) to J2SE level APIs which is what most Java developers are using today.
.NET Framework equivalents. If you take that route, you are using the Java language but not the java platform and you're locked in. If that's what people want, MS is definately the company to give it to them but they should be clear about what they are getting tied into.
That precludes automatically compiling an awful lot of Java source code - e.g. existing code which uses Swing, rmi, CORBA, sound, 3D and even newer APIs for logging, printing, crypto etc. It also closes the door to any existing J2EE API based code (e.g. JDBC 2.0 - of course EJBs and Servlets are non runners!)
The roadmap is clearly to migrate more recent code to the
"The focus seems to be on J++ developers, not Java developers. But personally, I will use J# iff:
.NET executable. "
.NET Framework Base Class APIs available through J# are not based on the J2SE APIs although in places the object models look similiar. For example, both have a base Object class from which all other classes inherit but even the APIs on this class are different. All of the auxiliary APIs for IO, Math, Collections, Security, Reflection also differ in too many ways to describe. Perhaps they will provide tools to automate the conversion of source from one API set to the other but don't expect it to be automatic.
.NET Framework is worse than the J2SE APIs or vice versa - they are just different.
.NET apps using the .NET Framework APIs. Java the platform (the JS2E APIs and VM) are not part of the deal.
* I have to make exactly zero changes to my Java to have it compile to both VM bytecodes and to a
That won't be possible. The
That's not to say that the
All Microsoft are facilitating with J# is allowing developers who know the Java language syntax to develop
It is a very difficult switch if development needs to continue at full speed during the transition.
- Planning - up front, and iterative
- Short release cycles - small incremental builds build confidence in the build system, test rig and final kit
- Simplify design - bite off the minimum amount of work for each release
- Use methaphors - use a common familiar naming system for features and components whenever possible
- Refactoring - refine code when necessary. A subject upon itself (check out Martin Fowlers book)
- Unit testing - unit test, unit test, unit test. If you want to write the code, you write the tests first. Run the tests as often possible (whenever you change the code) With a good unit test suite, accidently introducing bugs as a result of refactoring code isn't as likely
- Continuous integration - merge changes as quickly as possible, keeping everone in sync. A decent configuration management tool is essential.
- On site customer - customer has direct input to requirements/priorities.
- Code ownership - or rather collective ownership of code. If you see something that should be changed, you don't need to request permission. Do it.
- Coding standards - required for Collective ownership to be possible. Rules are required to ease readability
- Pair programming - As described already
- 40 hour week - if you're burnt out you'll make mistakes
The point is, XP uses *all* of the above practices - they're an interdependent matrix of practices in which each supports many others. (For example, continuous integration facilitates small releases which in turn facilitates iterative planning etc, etc.)If you choose not to implement several of these practices then the methology starts to break down. I think this is what makes it so difficult for a lot of engineering organizations to switch to XP - there is simply an awful lot to change, a lot more than buying desks which can seat two people...
I, for one, am glad I'm aware of issues like this and can avoid it (Mozilla :) - it's frustrating to think of millions of others without so much as a clue the vunerability exists...
I wonder how long it will take the 5 squillion users running IE5.x to install that patch(let alone the 50 squillion running IE4.x) How quickly will coporate IT departments roll it out? Combined with Verisign accidently issuing Class 3 certs to some bloke with the common name "Microsoft Corporation" Microsoft must be just waiting for the class action suits to roll in.
I can't wait until .net comes. Think about it, I can just forget my windows passwords I keep in my head because they will be redundant
IT admins, go to brown alert...
- open up your data to other patforms, programming languages (not markup languages) and tiers in the enterprise.
- participate and adhere to a published and accepted DTD (Schema) for the XML data you are generating.
- choose the right underlying protocol. Unfortunately the prime candidate for the "ideal" protocol for tranporting XML content is causing market segmentation mainly due to the disparity of environments into which XML data is used. SOAP (XML over HTTP) is viable only for a low volume of messages or very high speed networks. XML over IIOP is more efficient but lacks standardization (what does your IDL interface look like). Then you've got other proprietary solutions like MQSeries and other budding standards like XML-RPC which are muddying the waters.
- Lastly, the cost of marshalling/unmarshalling XML documents using something like the DOM API is prohibitive. I know, I know, you can get your hands dirty by using SAX directly but it is extra work and usually ends up specific to a particular XML document DTD or Schema. JDOM is a decent enough API but is Java only.
I'm not knocking XML - it a young specification with massive industry support which will hopefully give rise to mature systems. Lets keep those vendors from hijacking either the XML or vertical industry data specifications though. Otherwise you may as well use byte streams - same vendor lock-in but more efficient.Lets drop any arguments about "The American Way (tm)" What you've got here is a representative of the largest software in the company saying that competition from volunteers is bad. Exactly who's interests is he defending? I am baffled that this is even a debatable issue?