dude, the EU is the biggest joke in the western world. it's corrupt, bitchy, old-school and flawed. i'm not saying the US rules, but the EU is it's own biggest problem!
right now they are holding up the process because of an arbitraty, unspecified opinion they hold on what software documentation should be.
NEWS FLASH: what EU company has come close to M$'s success in the software world. the EU knows jack shit about software development. i quote from a EUROPEAN M$ employee: 'Europe develops a lot of stylish software that doesn't work.' No, this is not out of context.
Europe doesn't know how to develop competetive software, and they are complaining about the quality of documentation from the world's most successful software company??? What the hell?
And what the hell is up with Windows XP - N? That had to be the worst idea ever from the pokiest bureaucracy ever. seriously, what the hell is that about???? they actually thought people would want to buy and use such a piece of crap.
anyway, the EU sucks.
and, yes, i lived in europe for a good number of years, and see why it is never going to live up to US competetive standards.
monopolies hurt consumers, not competitors. M$ hasn't necessarily overcharged for anything.
has anyone ever thought that the dynamics of software in the marketplace are very different than things like oil, electricity and cars? software is not a physical asset.
it's possible that software tends towards a monoculture, where compatibility at some level drives decision making, rather than just dollar amount.
i just think that software is a very different beast, and it may tend towards a single platform dominating. in this case, it appears to be M$ which has invested heavily in compatibility of its own products, hence increasing the value of their software to users.
perhaps the economics of software are different than the economics of physical products that ship by the unit.
and if something delays or complicates the process, the whole world will hear about it.
if groups in the MA govt. start complaining that they are losing documents, having problems with maintaining multiple versions of the documents, etc., then this effort will be known as the biggest boondogle in history.
and anybody who recommends this path in the future will be sharply reminded of this failure.
i give the initiative about a 1 in 20 change of success.
when windows 95 came along, everyone complained about stability since win2k/xp, stability is less of an issue now security is in the spotlight
ms is focusing on the security factor more than ever before. they have at least doubled the amount of time required for dev projects simply to handle security concerns. their internal processes have changed significantly to incorporate security reviews, notably what they call 'thread modelling'
heck, i knew one developer at MS who spent 8 months doing thread modelling on an API that didn't even have any IPC whatsoever - just a flat library. 8 months! why? well, it is commonly used, so they made the investment.
what i'm trying to say is that MS has invested money into areas where they feel the most pain. stability has been 1 before, and they improved it significantly (not perfectly). security is where they are making new investments, and it will pay off for them, but i still wouldn't expect perfect security
but, the security situation in vista well be better, i'm almost certain.
and with WCF, they have probably gone overboard on security. but that's another story
MS XML formats were to be available within 1 year of his decision.
problem sovled? don't know
however, you can guarantee there will be a slew of readers that will pop up for it, once it is available.
migrating from current formats to MS's XML format is a far more practical solution for handling their 1M+ documents. furthermore, you don't have the same transition problem that you would have if you migrated to a completely foreign standard.
plus, let *office and OO implement MS's format. heck, they could probably do that within a week;-)
- he works as the CIO for a state govt, and expects his personal edicts for mass change to be 'a'political decisions - he actually stated he was trying to mimic the structure of the UN. that's kind of weird - he forgot about disabled users in making this decision - a big omission for a state CIO - he didn't plan for support - he didn't have a clear migration path for the state's 1M+ documents
and because of the situation he created, he got himself shut down by politicians who saw him as a loose canon.
he decided to convert a state's existing document format to an open format, in the midst of a format war between MS and Novell/IBM/Sun, and say that he was just trying to do the right thing.
so, he decided to put his state on the front line of the war, and with the complicatioins of campaign contributions, elections, etc., he effectively stuck his hand into a political bea nest.
ok, if the french are going to spearhead this effort, i'm expecting something like minitel, the pride of the french, government backed, software industry
i don't know why exactly, for maybe cultural or economic reasons, europe has a hard time competing in the world of commercial software.
and now the govt is getting behind it. anytime something like this happens in europe, you end up with things like: - farm and vineyard subsidies - french movies - minitel
with the exception of the food, the rest of the stuff has shown limited success, especially within the global market.
i suspect an EU/French govt. backed software initiative will be the same.
for some reason, there is a belief that anything for the greater good must be govt. sponsored, controlled, and beat to death
just an opinion.
BTW - if you haven't seen it yet, check out minitel. it's great if you like retro style character based dumb terminal application. www.minitel.fr - no screen shots, but you may be able to gleen some stuff from the site.
other than that, i see a lot of try/catch/wrap/rethrow with an unchecked exception
why does EJB 3.0 move to unchecked exceptions? because checked exceptions cause too many issues for programmers. really - doing this in EJB 3.0 is a major shift for them. i'm sure it was a huge debate.
well, then you must work with good programmers most of the junior programmers i've seen do so, and there are a lot of junior java programmers
what else can you do if you are implementing an interface that doesn't declare the exception you have to handle? catch, wrap and rethrow as an unchecked exception.
and if you find this acceptable, other posters think that this practice is a sin.
in other words - there is little or no consensus on how to handle this.
hence, EJB 3.0 uses unchecked exceptions - whether people believe in it or not
ActiveX, COM, VB were pretty hokey, and never lived up to their expectations in fact, COM was mostly used to communicate between languages, rather than a component architecture and DCOM/MTS - don't even get me started.
however,.net has been different. MS is doing something they never really did before - take their sweet old time to produce quality.
check out C# 3.0 and LINQ* - it's pretty amazing.
and if you think.net is flawed, then why is Java changing its original 'formula' to look like C# to such a great extent. really - generics, attributes, first class treatment of iterators, etc.
now, i'd like to see what happens to EJB and J2EE when WCF comes out. EJB was thrown together quickly with little or no feedback based on usage. WCF represents nearly 7 years of R&D at Microsoft, with iterations of usage in applications, feedback, etc. and it's based on lessons learned from DCOM.
In any case, the.net stuff at MS is doing things much differently than the stuff you saw at of MS before.
I for one like where they are going, and I think they are generally producing higher quality products than most other vendors right now.
EJB had this pie in the sky concept of becoming a general purpose distributed enterprise component architecture, where applications could be integrated SOA style (before SOA was a term). Internal IBM divisions saw this as a way to integrate their various applications. None of this ever actually happened.
EJB Entity beans were meant to be coarse grained persistent distributed components. Session beans were meant to be a means of remoting. IIOP was adopted to integrate with legacy CORBA apps. Hardly anyone uses EJB this way.
People use EJB these days mostly to build web applications. Entity beans are used to do OR mapping, which is a tough way to go. Session beans are used for state tracking and state sharing. Most EJB invocations are local, hence the Home interface introduced in EJB 2.0.
In other words, its kind of like buying a house because you need lumber.
It was clear when the spec first came out that complexity and complex interdependencies would prevent the grand vision from happening.
My original take on it was that it wouldn't achieve the desired goal (and it hasn't). In fact, back then, some of us were advocating XML on the wire and XML as an IDL. This is kind of what SOAP/WSDL became. But that has it's own issues.
In any case, I would have implemented a very minimal interface for J2EE and let someone else take the arrows. MS took 2 years just to think about LINQ in C# 3.0 and over 6 years so far to build WCF! And it hasn't seemed to hurt its market share so far.
I was at an all day private meeting once with Sun on J2EE. I would summarize it as this - they promised to fix it over time, and to prove it told us that they put their Solaris dev manager in charge of Java. This caused some rifts in Sun, but they were getting beat up too much over Java/J2EE's immaturity. So, they gave it to one of their most accomplished dev managers.
something like that would make sense i think this is what Bill Joy was trying to achieve when he insisted on putting checked exceptions into Java, AT THE LAST MINUTE.
you can argue that they can be used when makes sense, but if you are calling into a library that declares them, you have to deal with it, even though you might not be able to at the time.
the result, as pointed out earlier, is that 90% of programmers tend to do nothing - catch (Exception exc) {exc.printStackTrace();}
and as far as rethrowing it, they might not be in a position to rethrow it properly - e.g. JSP page
it was a neat idea, but one that has many, many issues.
i've seen java SEGV many a time, actually. on revenue generating production applications - huge systems.
In once case it was crashing in some part of the JVM related to weak references, although the app wasn't using them. In another case it was in a WebLogic JNI library.
you still have to demarkate your transactions, just as with.net
but, yes, spring and hibernate started with a focus on OR mapping. EJB entity beans were kind of meant for something else originally, that's why they don't quite do the trick.
I was told that Entity beans were meant to be a 'coarse grained distributed persistent component' with few, if any, relationships. This becomes apparent when you try to use them.
to some degree, there was some cross over of personnel between the divison of IBM spearheading EJB and Sun Microsystems. some of the people on either team went way back i think that had at least something to do with it
IBM was also threatening to start up their own version of Java at the same time. Sun didn't want to see Java move in 2 different directions, and J2EE became a way of gluing it together for a longer haul.
however, you are beginning to now see another push to split java into an open source version and a sun version. so, sun will have to do something again.
EJB had this pie in the sky concept of becoming a general purpose distributed enterprise component architecture, where applications could be integrated SOA style (before SOA was a term). Internal IBM divisions saw this as a way to integrate their various applications. None of this ever actually happened.
EJB Entity beans were meant to be coarse grained persistent distributed components. Session beans were meant to be a means of remoting. IIOP was adopted to integrate with legacy CORBA apps. Hardly anyone uses EJB this way.
People use EJB these days mostly to build web applications. Entity beans are used to do OR mapping, which is a tough way to go. Session beans are used for state tracking and state sharing. Most EJB invocations are local, hence the Home interface introduced in EJB 2.0.
In other words, its kind of like buying a house because you need lumber.
It was clear when the spec first came out that complexity and complex interdependencies would prevent the grand vision from happening.
My original take on it was that it wouldn't achieve the desired goal (and it hasn't). In fact, back then, some of us were advocating XML on the wire and XML as an IDL. This is kind of what SOAP/WSDL became. But that has it's own issues.
In any case, I would have implemented a very minimal interface for J2EE and let someone else take the arrows. MS took 2 years just to think about LINQ in C# 3.0 and over 6 years so far to build WCF! And it hasn't seemed to hurt its market share so far.
I was at an all day private meeting once with Sun on J2EE. I would summarize it as this - they promised to fix it over time, and to prove it told us that they put their Solaris dev manager in charge of Java. This caused some rifts in Sun, but they were getting beat up too much over Java/J2EE's immaturity. So, they gave it to one of their most accomplished dev managers.
point is that.NET and many other technologies can do distributed transactions without and EJBish thing.
actually, it is JTA/JTS that makes distributed transactions possible.
EJB just allows you to remote your transaction with remote invocations, which is very very rare.
Slashdot Mirror
so, by this logic, if you fire a visionary CEO, your stock will shoot up.
sorry, jonathan schwartz, but it looks like your days could be numbered.
i can see bill gates putting on the war paint right about now,
calling for his sword and shield.
he's definitely taking control of the company once again,
probably shifting focus from his humanitarian efforts to operating his company.
in a few years time, i imagine the company will have created several new large revenue streams, as well as bolstering the old ones.
couldn't resist a bit of flamebate.
The EU doesn't actually suck.
But I do believe EU commission is a bit insane.
http://europa.eu.int/comm/commission_barroso/kroes /
Neelie.Kroes@cec.eu.int
Hammer her.
I personally don't agree with the EU case against MS.
But, let's slashdot her!
dude, the EU is the biggest joke in the western world.
it's corrupt, bitchy, old-school and flawed.
i'm not saying the US rules, but the EU is it's own biggest problem!
right now they are holding up the process because of an arbitraty, unspecified opinion they hold on what software documentation should be.
NEWS FLASH: what EU company has come close to M$'s success in the software world. the EU knows jack shit about software development.
i quote from a EUROPEAN M$ employee: 'Europe develops a lot of stylish software that doesn't work.'
No, this is not out of context.
Europe doesn't know how to develop competetive software, and they are complaining about the quality of documentation from the world's most successful software company???
What the hell?
And what the hell is up with Windows XP - N?
That had to be the worst idea ever from the pokiest bureaucracy ever.
seriously, what the hell is that about????
they actually thought people would want to buy and use such a piece of crap.
anyway, the EU sucks.
and, yes, i lived in europe for a good number of years, and see why it is never going to live up to US competetive standards.
monopolies hurt consumers, not competitors.
M$ hasn't necessarily overcharged for anything.
has anyone ever thought that the dynamics of software in the marketplace are very different than things like oil, electricity and cars?
software is not a physical asset.
it's possible that software tends towards a monoculture, where compatibility at some level drives decision making, rather than just dollar amount.
i just think that software is a very different beast, and it may tend towards a single platform dominating.
in this case, it appears to be M$ which has invested heavily in compatibility of its own products, hence increasing the value of their software to users.
perhaps the economics of software are different than the economics of physical products that ship by the unit.
just a thought.
and if something delays or complicates the process, the whole world will hear about it.
if groups in the MA govt. start complaining that they are losing documents, having problems with maintaining multiple versions of the documents, etc.,
then this effort will be known as the biggest boondogle in history.
and anybody who recommends this path in the future will be sharply reminded of this failure.
i give the initiative about a 1 in 20 change of success.
when windows 95 came along, everyone complained about stability
since win2k/xp, stability is less of an issue
now security is in the spotlight
ms is focusing on the security factor more than ever before.
they have at least doubled the amount of time required for dev projects simply to handle security concerns.
their internal processes have changed significantly to incorporate security reviews, notably what they call 'thread modelling'
heck, i knew one developer at MS who spent 8 months doing thread modelling on an API that didn't even have any IPC whatsoever - just a flat library.
8 months!
why? well, it is commonly used, so they made the investment.
what i'm trying to say is that MS has invested money into areas where they feel the most pain.
stability has been 1 before, and they improved it significantly (not perfectly).
security is where they are making new investments, and it will pay off for them, but i still wouldn't expect perfect security
but, the security situation in vista well be better, i'm almost certain.
and with WCF, they have probably gone overboard on security.
but that's another story
define open? defined? published? standard? office xml falls into those categories at this point
MS XML formats were to be available within 1 year of his decision.
;-)
problem sovled?
don't know
however, you can guarantee there will be a slew of readers that will pop up for it, once it is available.
migrating from current formats to MS's XML format is a far more practical solution for handling their 1M+ documents.
furthermore, you don't have the same transition problem that you would have if you migrated to a completely foreign standard.
plus, let *office and OO implement MS's format.
heck, they could probably do that within a week
a few things to consider:
- he works as the CIO for a state govt, and expects his personal edicts for mass change to be 'a'political decisions
- he actually stated he was trying to mimic the structure of the UN. that's kind of weird
- he forgot about disabled users in making this decision - a big omission for a state CIO
- he didn't plan for support
- he didn't have a clear migration path for the state's 1M+ documents
and because of the situation he created, he got himself shut down by politicians who saw him as a loose canon.
he decided to convert a state's existing document format to an open format, in the midst of a format war between MS and Novell/IBM/Sun, and say that he was just trying to do the right thing.
so, he decided to put his state on the front line of the war, and with the complicatioins of campaign contributions, elections, etc., he effectively stuck his hand into a political bea nest.
he wasn't thinking straight.
ha ha, well put! quality is NOT the way to win in this industry, this is certain.
it's just an operating system.
. jpg
and kernel rebuilds make it hard for an enterprises to accept.
screen shot of a linux kernel panic:
http://static.flickr.com/38/79844669_3368c9d8a5_s
ok, if the french are going to spearhead this effort,
i'm expecting something like minitel, the pride of the french, government backed, software industry
i don't know why exactly, for maybe cultural or economic reasons,
europe has a hard time competing in the world of commercial software.
and now the govt is getting behind it.
anytime something like this happens in europe, you end up with things like:
- farm and vineyard subsidies
- french movies
- minitel
with the exception of the food, the rest of the stuff has shown limited success, especially within the global market.
i suspect an EU/French govt. backed software initiative will be the same.
for some reason, there is a belief that anything for the greater good must be govt. sponsored, controlled, and beat to death
just an opinion.
BTW - if you haven't seen it yet, check out minitel.
it's great if you like retro style character based dumb terminal application.
www.minitel.fr - no screen shots, but you may be able to gleen some stuff from the site.
well, maybe not 90%, but i see it far too often
other than that, i see a lot of try/catch/wrap/rethrow with an unchecked exception
why does EJB 3.0 move to unchecked exceptions?
because checked exceptions cause too many issues for programmers.
really - doing this in EJB 3.0 is a major shift for them.
i'm sure it was a huge debate.
well, then you must work with good programmers
most of the junior programmers i've seen do so, and there are a lot of junior java programmers
what else can you do if you are implementing an interface that doesn't declare the exception you have to handle?
catch, wrap and rethrow as an unchecked exception.
and if you find this acceptable, other posters think that this practice is a sin.
in other words - there is little or no consensus on how to handle this.
hence, EJB 3.0 uses unchecked exceptions - whether people believe in it or not
ActiveX, COM, VB were pretty hokey, and never lived up to their expectations
.net has been different.
.net is flawed, then why is Java changing its original 'formula' to look like C# to such a great extent.
.net stuff at MS is doing things much differently than the stuff you saw at of MS before.
in fact, COM was mostly used to communicate between languages, rather than a component architecture
and DCOM/MTS - don't even get me started.
however,
MS is doing something they never really did before - take their sweet old time to produce quality.
check out C# 3.0 and LINQ* - it's pretty amazing.
and if you think
really - generics, attributes, first class treatment of iterators, etc.
now, i'd like to see what happens to EJB and J2EE when WCF comes out.
EJB was thrown together quickly with little or no feedback based on usage.
WCF represents nearly 7 years of R&D at Microsoft, with iterations of usage in applications, feedback, etc.
and it's based on lessons learned from DCOM.
In any case, the
I for one like where they are going, and I think they are generally producing higher quality products than most other vendors right now.
i'll restate this:
harsh, perhaps.
EJB had this pie in the sky concept of becoming a general purpose distributed enterprise component architecture, where applications could be integrated SOA style (before SOA was a term).
Internal IBM divisions saw this as a way to integrate their various applications.
None of this ever actually happened.
EJB Entity beans were meant to be coarse grained persistent distributed components.
Session beans were meant to be a means of remoting.
IIOP was adopted to integrate with legacy CORBA apps.
Hardly anyone uses EJB this way.
People use EJB these days mostly to build web applications.
Entity beans are used to do OR mapping, which is a tough way to go.
Session beans are used for state tracking and state sharing.
Most EJB invocations are local, hence the Home interface introduced in EJB 2.0.
In other words, its kind of like buying a house because you need lumber.
It was clear when the spec first came out that complexity and complex interdependencies would prevent the grand vision from happening.
My original take on it was that it wouldn't achieve the desired goal (and it hasn't).
In fact, back then, some of us were advocating XML on the wire and XML as an IDL. This is kind of what SOAP/WSDL became. But that has it's own issues.
In any case, I would have implemented a very minimal interface for J2EE and let someone else take the arrows.
MS took 2 years just to think about LINQ in C# 3.0 and over 6 years so far to build WCF!
And it hasn't seemed to hurt its market share so far.
I was at an all day private meeting once with Sun on J2EE.
I would summarize it as this - they promised to fix it over time, and to prove it told us that they put their Solaris dev manager in charge of Java.
This caused some rifts in Sun, but they were getting beat up too much over Java/J2EE's immaturity.
So, they gave it to one of their most accomplished dev managers.
something like that would make sense
i think this is what Bill Joy was trying to achieve when he insisted on putting checked exceptions into Java, AT THE LAST MINUTE.
you can argue that they can be used when makes sense, but if you are calling into a library that declares them, you have to deal with it, even though you might not be able to at the time.
the result, as pointed out earlier, is that 90% of programmers tend to do nothing - catch (Exception exc) {exc.printStackTrace();}
and as far as rethrowing it, they might not be in a position to rethrow it properly - e.g. JSP page
it was a neat idea, but one that has many, many issues.
BTW - EJB 3.0 now uses runtime exceptions!
i've seen java SEGV many a time, actually.
on revenue generating production applications - huge systems.
In once case it was crashing in some part of the JVM related to weak references, although the app wasn't using them.
In another case it was in a WebLogic JNI library.
you still have to demarkate your transactions, just as with .net
but, yes, spring and hibernate started with a focus on OR mapping.
EJB entity beans were kind of meant for something else originally, that's why they don't quite do the trick.
I was told that Entity beans were meant to be a 'coarse grained distributed persistent component' with few, if any, relationships.
This becomes apparent when you try to use them.
EJB 3.0 is actually sort of based on hibernate.
to some degree, there was some cross over of personnel between the divison of IBM spearheading EJB and Sun Microsystems.
some of the people on either team went way back
i think that had at least something to do with it
IBM was also threatening to start up their own version of Java at the same time.
Sun didn't want to see Java move in 2 different directions, and J2EE became a way of gluing it together for a longer haul.
however, you are beginning to now see another push to split java into an open source version and a sun version.
so, sun will have to do something again.
harsh, perhaps.
EJB had this pie in the sky concept of becoming a general purpose distributed enterprise component architecture, where applications could be integrated SOA style (before SOA was a term).
Internal IBM divisions saw this as a way to integrate their various applications.
None of this ever actually happened.
EJB Entity beans were meant to be coarse grained persistent distributed components.
Session beans were meant to be a means of remoting.
IIOP was adopted to integrate with legacy CORBA apps.
Hardly anyone uses EJB this way.
People use EJB these days mostly to build web applications.
Entity beans are used to do OR mapping, which is a tough way to go.
Session beans are used for state tracking and state sharing.
Most EJB invocations are local, hence the Home interface introduced in EJB 2.0.
In other words, its kind of like buying a house because you need lumber.
It was clear when the spec first came out that complexity and complex interdependencies would prevent the grand vision from happening.
My original take on it was that it wouldn't achieve the desired goal (and it hasn't).
In fact, back then, some of us were advocating XML on the wire and XML as an IDL. This is kind of what SOAP/WSDL became. But that has it's own issues.
In any case, I would have implemented a very minimal interface for J2EE and let someone else take the arrows.
MS took 2 years just to think about LINQ in C# 3.0 and over 6 years so far to build WCF!
And it hasn't seemed to hurt its market share so far.
I was at an all day private meeting once with Sun on J2EE.
I would summarize it as this - they promised to fix it over time, and to prove it told us that they put their Solaris dev manager in charge of Java.
This caused some rifts in Sun, but they were getting beat up too much over Java/J2EE's immaturity.
So, they gave it to one of their most accomplished dev managers.
point is that .NET and many other technologies can do distributed transactions without and EJBish thing.
actually, it is JTA/JTS that makes distributed transactions possible.
EJB just allows you to remote your transaction with remote invocations, which is very very rare.