Corba language neutrality gone? 132
Linuk writes "Here's an interesting article, CORBA 3.0 POSTMORTEM, about the OMG's adoption of EJB as its eagerly awaited component spec. It argues that OMG has now given up on its vendor neutral and language independent pretentions. "
Objectwatch is an M$ Consulting/Training Outfit (Score:1)
objectwatch is mainly a consulting operation
with a focus on M$ technologies...
This doesn't necessarily make their comments
wrong, and Sun may want to be a little
Microsoft,
the biases here
Heard Roger Sessions speak once... (Score:1)
While Microsoft does have the lead in this area at the moment, I'd say EJB is right now where MS was in 1996-ish, and gaining fast (the only reason MS got the head-start was because all they have to do is say "this is a standard" and it is, wheras Sun and OMG both have to deal with this bizarre thing called "user feedback").
He also claimed that MS is working very hard on making COM interoperable with the other standards and neither of the others was making any effort in this area (he didn't make any attempt to back up either of these completely false statements). I picked him up on this one, and finally got a grudging admission that "yeah, EJB *will* be great".
He also claimed that the only thing EJB has going for it is the Java Platform, and that unless you buy completely into Java Everywhere, you shouldn't even consider it (and made some disparaging remarks about Java on the client side, which is supposed to turn everyone off using it on the server side too).
Sorry for the long post, but I think this makes it abundantly clear that Roger Sessions is anything but an unbiased observer. He's a fully paid off Microsoft lacky, and the only reason he doesn't work for Microsoft is that this way, they can claim that he's an objective outsider.
Stuart (sab39, but can't remember my password).
Corba sadness -- Microsoft madness (Score:1)
COM and, to a lesser extent CORBA, only work to the extent that you sacrifice your freedom and flexibility to the vendor agenda. Yes, they both work to a degree and people are actually using them in real life.
But.
But the real issue is that these things are all being brought to market on a vendor product cycle rather than being allowed to develop "ecologically" in sync with the heterogeneous demands of distributed processes and the evolution of the net.
--------
Not worth the trouble (Score:3)
hype is irrlevant to the real world of appliations and systems and
software development in the GUN-Linux-"Free Software" world
that most readers here dwell in, except to the degree that a few
projects have partially (and really, very, very partially) used some
aspects of CORBA or attempted to use CORBA for object
integration. Notably GNOME and KDE. That implementation
will always remain, at best, partial and eventually will phase out.
This does not mean that GNOME and KDE will phase out,
however. Developers who actually have to write apps despise
CORBA and for good reason.
Another poster noted that CORBA and the "object model"
of development is dead, but that the horse is still twitching.
So long as the horse is still twitching, the hype and buzz will
be good for one's career in the proprietary corporate world,
particularly in IBM centric shops needing mid-level integration
using IBM tools and of course in MS shops using exclusively
MS platforms with COM as the integration method and in Sun
shops using proprietary SUN unixes and proprietary database
systems and proprietary SUN./IBM Java.
CORBA and its many variants (including JavaBeans and all
the variations of Microsofts's COM, really) is too unwieldy and
complex. These variations of CORBA are inherently inconsistent
and often incompatible in practice. Partly this is intentional, as each
vendor wants to lock in customers and developers. But mostly
it is because CORBA and COM and SOM and Java the whole
works is a technology which is alread passe and lifeless and ugly
and unwieldy. I am speaking from experience here having worked
with IBM"s SOM years ago when it was held out as the
final solution for object modeling at the system level. Well,
that was abandoned for CORBA. CORBA is being abandoned
for Java, and on and on with the hype.
It's important to understand the role of these technologies and
their purpose. Their only purpose, really, is to provide a framework
wherein vendors can "distribute" software or code from owned
"servers" to paying "clients". Sort of like renting software. That
is it. There is nothing more to it. The rest is utter hype.
Does this mean that I am opposed to object oriented software
development? Not at all. I love C++ for gui development, for
music software, and much more, and I use it. I like Python
a lot even though I've not used it much to date, and Lisp is the
grandfather of it all -what I stareted with. However, at the system
level I do not feel that the kind of object integration hyped
by these vendors (and it really is the vendors, not the
programmers, who hype it) is desirable - especially in the free
software world, which holds the key to the future and is where
all of the energy and "light" is right now.
The future is in using simple scripting languages and XML and
so forth in combination with solid systems and open data
formats wherein the *DATA*, not code, is the medium of integration
between applications and systems. Nothing can be simpler, and
nothing else really works, in the long run. Sounds too simple
to be true, but the truth is better than marketing hype by bold
faced liars intent only on advancing their own careers. XML and
its ilk is the future, not CORBA.
Scripting languages which allow integration and open protocols
for networking are already here. Some of this may have object
oriented features, which is fine and dandy. But, that is vastly
different in nature from "system level object integration" which
really means, beneath all the hype, only one thing - let our
proprietary object model integrate your system. We will rent
you code which we will distribute to you for a price. This code can
run your toaster, your tv and your home computer. Leave the
driving to us.
We read a lot these days about Linux meeting the challenge of
enterprise level. Ho, hum. What a boring topic. "Enterprise"
means "corporate". Linux and free software (GNU, etc) was not
created to serve faceless, lifeless, anti-god corporations but to
serve people. To empower people to take control of their own
software or at least not to be controlled in merely using software.
Translated to the level of concrete applications, this means
continuing to develop good apps using open protocols and to
make source code available, object oriented or not, and to use
integration tools provided with unix (and GNU equivalents which
are often better) to "layer" small tools and apps to create
subsystems for any purpose - even for corporate enterprise.
But, we play by our rules, not the rules of Java as defined by
Sun or COM as defined by MS. Above all, keep it simple.
a programmer - over 40
C++ speed (Score:1)
one is when your system has a lot of object creation and destruction. C++ has to run the destructor every time, plus has to deal w/ the memory freeing overhead. Java ('cause of the garbage collection) can put it off till the system load is a bit lower, or if you have _lots_ of ram for ever.
i'm not trying to say that java is faster than c++, just that c++ is not _always_ faster than java.
I agree 100% about the use of OO languages.
henri
Am I getting old or something?? (Score:2)
you write your code in c, compile it and run it.
it works when you and 2 other people test it.
you move it out to production, 10000 people hit it. boom it dies. why? your SINGLE computer can't handle the load.
so you start to distribute chunks of it, i'll open a socket to this other computer and that way we can spread the load!
so you spend hours/days/weeks writing and testing and breaking your code up into smaller chunks that can run independently of each other and writing a general protocol between them so you don't have to re-write the distribution part every time....
hmmm... starting to look familiar.
wouldn't it have been easier to use some sort of 'component spec' that hides the transfer protocol, has been tested, is documented, and could possibly work with some other vendors components? (and _maybe_ you could use some 'opensource off the shelf' components and save yourself some time and effort in the first place.)
you can still write your code in C, look at GNOME (jeez, i hope that's not written in C++ or i'll look kinda foolish here)
henri
EEs went through this already (Score:2)
Now the same thing is happening in software, but it'll take a while until everyone agrees on some sort of standard. I expect most of the long-term impetus for this to come from open source developers who want to make long-distance collaboration easier, even though commercial developers have a MAJOR interest in making it easier to assemble programs from lists of objects that all fit together easily without a lot of wiggling and cramming.
I have no idea yet what that standard will be. UML is only a few years old. Conceptually, it's about where circuitry schematic design was in 1910 or so, and it didn't really get "hardened" until 1925 or later.
--Robin Miller
Cheap Computing columnist
Oh, rot. (Score:1)
But the fact is, a component spec isn't necessarily tied to a language. So they like the EJB components: that means someone will do compatible components in C++ as well. It's not as if the components are inherently Java-specific.
Most of you are whining because they didn't go with the Windows of the OO language world (C++). Think about it.
C++ Garbage Collectors (Score:1)
While I would agree that Java programs can be faster than C++ programs, anything written in Java can always be rewritten and made faster in C++ if you are willing to commit the time and knowledge to get it done.
C++ Garbage Collectors (Score:2)
The real issue is that Java is much easier to program, much more portable, and arguably easier to maintain. While it may be worth programming some things in order to squeeze out some more performance, there are cases where Java will be far more cost effective.
Right tool for the right job.
Read the OMG Press Release (Score:4)
He basically claims that OMG is giving up language neutrality. Here is a quote from the OMG press release [omg.org] that he is supposedly commenting on:
The press release is simply a joint announcement from Sun and OMG announcing that there will be a close collaboration between EJB and CORBA. Importantly, EJB will be supporting the core of CORBA's network communication model: IIOP, which pretty much guarantees that you can write your objects in any language and on any platform, as long as you can make TCP sockets.
I must say that this guy's experience is really, really, far from my own and that ceretainly shapes his very, very different interpretation of this press release. He says that he sees half of all programmers who are working with object integration programming with VB. I certainly don't.
I think people should read the OMG release themselves and draw their own conclusions, but I read it as a commitment from Sun to cooperate with OMG to come up with a vendor neutral object specification ... something to address the fundamental questions of vendor and platform dependence raised by Microsoft's DOM.
Basic Java issues that make it slower than C++ (Score:1)
The array access is probably still an issue, I think there may have been advances in that area by newer VM's but I can't say for sure.
There are well-known techniques for hoisting
array bounds checks out of loops. This makes
array bounds checking essentially free. The good
JIT's do this already, although there are probably
some cases that they can't yet analyse properly.
This will improve with time, and as the previous
poster mentioned, without source-code changes.
Only one protocol matters: HTTP, SMTP, HTML (Score:1)
Hmm, I'm not sure whether or not this is a
troll or whether you need the clue stick
liberally applied to your skull, Jeff. Do
remember that using HTTP in areas like
wireless networks, medical equipment and
process control nets is not the most advisable
approach.
I think I'll go for the clue stick
*twack* *twack* *twack*
Roger Sessions & Microsoft (Score:3)
Roger Sessions originally worked on the CORBA Persistance standard, which was subsequently rejected by the OMG. Ever since that unfortunate mishap, he has decided to side with Microsoft and print very anti-CORBA messages on his ObjectWatch site (read some of his other articles). Be aware that all he does is Microsoft/COM now and that many of his claims for COM and COM+ are speculative and somewhat misleading (at best).
I have worked with both CORBA and COM. I have had to explain the differences in the object models over and over, and I have developed in both environments. COM works well if you are a Microsoft shop, with all Microsoft desktops, and you only run on a Microsoft LAN, interfacing to a Microsoft database. CORBA works if you have a distributed heterogeneous network across multiple platforms, and multiple languages.
'nuff said.
Hmmm... (Score:1)
Now in my mind a standard should encourage interopabilty first, AND sepertate from the IDL etc.. build up a good general IPC mechanism which can be generalized to dynamic libraries, internet connections, or whatnot, and then build the other stuff on top of it... the low level IPC functions should always be availible, those may be used for languages where the IDL mapping just doesnt work, or for small uses where you just need to comunicate.
in any case check out ILU
ftp://ftp.parc.xerox.com/pub/ilu/ilu.html
C++ is ALWAYS....No, not Always, Yes *ALWAYS* (Score:1)
EEs went through this already (Score:2)
CORBA's problems are the same as all the problems of all OOA/D technologies, methods, schemes. Since they don't have any formalism they pretend to have it by making overly complex (pommobabble) presentations. UML is really just a way to draw your object model, it doesn't do a lot other than that. Drawing your object model is important, especially if you've got a large team of implementors who all need to be on the same page but it doesn't get you any closer to implementation or improve you implementation.
Have you ever learned Booch? or OMT? They are much too complex (proof of this is in the list of successful projects which have relied upon them..) This is the achilles heel of OOA/D. There are libraries full of books that discuss the philosophy and outline "methods" which are overly complex and get your project nowhere. The trick to good OOA/D and programming is to be dynamic because you can never figure out all the problems until you start solving some problems and plans change. There is also a lot to be said about finding the right balance between planning for the future in your design but implementing no more than you need, CORBA has plenty of useless features because they were afraid to say "no" and they wanted it to be everything to everybody; the best CORBA brokers are the ones that implement the few pieces that are really needed and ignore the rest.
I don't know, I'm a professional object programmer and we use UML at work. I'm also a functional programmer and I'm becoming more and more disgrunteld with all the talk in the object community and the consistant lack of substance. I think that the free software community is going to be the break through for CORBA and it is because they aren't playing the CORBA game, they are doing what is needed.
Corba sadness (Score:1)
But the victims _are_ doing something about it. I was just lamenting that it would have been nice if we could interoperate with Win32 easily, like we could have if they'd adopted Corba.
Corba sadness (Score:1)
Corba sadness (Score:2)
I suppose it'll end up in the great bit-bucket of marginally used but superior technologies...
Oh goody... :( (Score:1)
With CORBA as it stood, there was even a fraction of a chance I could manage this. With JavaBeans, forget it.
Umm... Oracle? (Score:1)
There's no reason you have to use a Microsoft database. There are ODBC and OLE-DB providers to connect to Oracle and others.
We use Oracle running on big Sequent boxes at work, and the Microsoft stuff has no more trouble talking to them than anything else.
Are you sure you've used both?
I hope they give up language neutrality... (Score:1)
There are a lot of free CORBA implementations... (Score:1)
Is this REALLY losing language-independance? (Score:1)
Sure this might favour Java a little bit, but I can't see it tying developers to that language inextricably.
C++ Garbage Collectors (Score:1)
rewritten and made faster in C++
Possibly. But the difference won't be more than a few percent. If you really want speed, use C. Or better yet, use assembly. The question is whether your time and effort and the lost of portability is worth it.
The reason why this spec is necessary (Score:3)
The EJB component specification is AN implementation of the specification, it certainly allows other bindings to be implemented in the future. Without this spec, CORBA will always lack the few advantages that DCOM has by allowing binaries to be passed around and used by other ORB's. The objects will of course need to be platform-independant. If they're not java objects, then the OMG would have to create some platform indepent binary specification, thus duplicating Sun's efforts with java.
C++ is NOT always faster than Java... STILL TRUE (Score:1)
And what's this about Java programs needing to copy things unnecessarily? A "well-crafted" Java program doesn't need to do that either.
Finally, while Java programs always use the "new" syntax to allocate objects, it's really up to your virtual machine to decide where objects get allocated. A JVM could, conceivably, allocate short-lived object on the stack. And if you have a good heap allocator, that doesn't matter too much anyways. (HotSpot apparently has one that's significantly faster than any known C++ heap allocator, and some of its speed comes from GC-related optimizations)
This explains his Visual Basic "statistic" (Score:1)
--
Explanation of his Visual Basic stats (Score:1)
He specializes in M$ development. He gives talk on M$ development.
Now if he'd talked to pure Unix audiences, the VB component would have been ZERO. And that's probably closer to reality for server development than M$ audiences.
--
Only one protocol matters: HTTP, SMTP, HTML (Score:1)
Corba sadness (Score:1)
It's really easy to be a victim. But victims don't get things done
Not worth the trouble (Score:1)
Roger Sessions... (Score:1)
It makes him more money? It's a distributed object service, not the cure for cancer. He doesn't need any more reasons than money.
What about OpenStep/ PDO -- with or without CORBA? (Score:1)
There's nothing better I'd like to do than write one of the services, but security is something you can't do an amateur job with. I'm a complete crypto dunce. And from the look of it, it's one of the biggest and hairiest services of all, encompassing auditing, non-repudiation, domain policies, custom policies, principal authentication, and on and on. Seems terribly complicated to me at least.
What about OpenStep/ PDO -- with or without CORBA? (Score:2)
I need a freely-available ORB that implements DII, DSI, POA, and Security. The last one is important because I want to create a multi-user collaborative system based on MOO, and the only sane way to do security in this system is to authenticate the sender of a message. Your obj.foo() method is called, first thing you ask is "who wants to know?". The Security service gives you an answer with get_credentials(). I still can't get something as simple as that in a free ORB. Some offer me SSL, which is like giving me a secure phone line when I still don't have caller ID.
What about OpenStep/ PDO -- with or without CORBA? (Score:1)
Roger Sessions *knows* CORBA! (Score:1)
Personally I don't mind Java, and I don't think Roger Sessions went out of his way to make any negative comments about Java itself, he just made the fairly real-world comment that most 3-tier client-server distributed applicaiton developers work in C++, VisualBasic (I choke at this, but it's true), or even COBOL (also a choker).
I don't current work in Java, so it seems reasonable to me that anyone who is expecting that we should all move to Java just to use these scalability services in Enterprise Java Beans is not going to see the kind of quarterly results that they wanted if they base their whole developer product lineup around EJB. What if I need highly tuned compiled components and low level platform services access in my code? Should I go with EJB and code the guts of an EJB in another language, and use Java Native Interface to call some code in C? Sounds like too much work. All that BS about Java being as fast as C++ assumes that your system is constricted purely by network throughput. roger Sessions even echoed this common point and *agreed* with the Java folks that the performance of a system doesn't change much whether it's in C++, Java, or Visual Basic. Personally, I'll beleive the "experts" until I can find a test case in which that isn't true, but when I get there, I don't want to be stuck using JAVA when I need a high performance component.
I bet that a lot of companies are going for an all Microsoft/COM+ middle-tier for now, and using a COM to CORBA bridge or a COM to EJB bridge when necessary for future integration to non-microsoft platforms.
Objectwatch is an M$ Consulting/Training Outfit (Score:1)
Anyway, I got this from the home page's opening lines:
We specialize in offering training and consulting on Microsoft's distributed component architectures, including Java, COM, DCOM, MTS, Falcon, and Wolfpack. This web site is a valuable source of information about Microsoft's distributed object architectures, the architecture that Microsoft calls DNA (Distributed interNet Applications).
Roger Sessions is available to come to your company and teach courses on Microsoft distributed object technologies.
Roger Sessions' new book is COM and DCOM; Microsoft's Vision for Distributed Objects, published by John Wiley and Sons. This book gives an overview of the various technologies Microsoft has introduced to support distributed object applications, and to compete with mainframes for the commerce market. These technologies include Java, COM, DCOM, MTS (Microsoft Transaction Server), Falcon, Wolfpack, and a sophisticated framework for support of distributed transactions.
I can't say this guy is unbiased. I guess since the OMG made Java the middle tier standard instead of, oh say, Visual Basic or COM/DCOM, his business might be impacted???? I think his trustability with me just dropped a couple of magnitudes.
Read the OMG Press Release (Score:1)
Um, pardon me but doesn't Python also use a VM underneath, so that .pyc files (in theory) are also "binary portable"?
I agree with you about the still-present language independence though: The events could go in this order:
Am I getting old or something?? (Score:1)
Am I _that_ clueless?
re: Oh goody... :( (Score:2)
I hope they give up language neutrality... (Score:1)
Marshalling data over IDL has been a real handicap for CORBA: C-structs just aren't flexible enough. From what I know, COM is no better in this regard either.
Java and CORBA have some great features: however, it makes a lot of sense to drop CORBA's language-inflexibility and RMI's inscaleability in favour of CORBA/EJB.
Heard Roger Sessions speak once... (Score:1)
If James Gosling (say) had conducted a similar experiment, I suspect the numbers would be somewhat different...
I hope they give up language neutrality... (Score:1)
Programmers are faced with two alternatives:
1. use structs in the IDL, and write marshalling code to convert the object hierarchy into structs. This is certainly do-able, but ugly: code needs to be changed whenever the data object changes.
2. serialize the data object into a byte array (e.g. using Java serialization), and pass this as a sequence of bytes. This is unsatisfactory because (a) the IDL interface becomes meaningless and (b) it makes the IDL language dependent.
IMHO, the former approach is too painful to deal with, which is why I think it makes sense to explore language dependent alternatives to IDL.
Objectwatch is an M$ Consulting/Training Outfit (Score:1)
You definitely see that he is not too happy with Java view of the world in the book. On the back of the book it says "An expoert's unbiased appraisal of Microsoft's object technologies and how they can work for your enterprise" - well, I would not call it unbiased.
Calling Java proponents for "wannabees", "rebel alliance" and some other things does not give an impression of someone that strives to be unbiased and keep a neutral tone.
At least as far as I got in the book, I did not read all of it.
Am I getting old or something?? (Score:1)
And since OO many times is a good way to handle complex softway models, choosing the OO paradigm as a base for this interface architecture is not too bad.
Note that OMG is not only about defining how objects communicate with each other, their effort is to provide all sorts of standardised interfaces related to software objects.
However, I think that there is a bit too much of trying to be buzzword compliant in some cases.
CORBA is certainly not the answer to all interoperability needs and it won't solve all interoperability/integration problems by just plugging in CORBA interfaces everywhere.
I think CORBA 3.0 is a step on the way of making it more useful and allowing integration with EJB is good.
What a real disappointment... (Score:1)
I really hope they change their mind on this matter. I do agree with the article though that the proposal in its current state is just too large and complex. I guess that is one of the major drawbacks of design by committee, you end up with huge, bloated specifications... they should go back to the idiom of KISS.
What about OpenStep/ PDO -- with or without CORBA? (Score:1)
I need a freely-available ORB that implements DII, DSI, POA, and Security
Looking at the TAO website (and having worked with it last year for a bit), it seems like TAO is pretty near a full compliment. You specifically mention DII, DSI and POA (none of which are services, BTW) all of which TAO has (in fact TAO was the first orb that had POA AFAIK). They don't have security according to their docs, but the security spec isn't terribly complicated. Why not help them implement it?
What about OpenStep/ PDO -- with or without CORBA? (Score:1)
There is also MICO [uni-frankfurt.de].
I am not knocking OpenStep, I program in it every day. But there are some great things that CORBA allows you to do without forcing everyone to use the same platform/language, etc.
Stephen Blake
is it dead, or merely mutated? (Score:1)
so, is there any possibility of taking JavaBeans and decaffinating them? to wit, create a non-Java implementation of the exact same set of protocols for doing the job and imlement them in something you can call C++Beans, or PerlBeans, or PythonBeans, or maybe even (caution flame-bait ahead) VisualBasicBeans
curious,
sdp
C++ speed (Score:1)
lots of objects, reflection, inheritance, threads,
A good programmer can probably pull of some tricks to get it working but the Java solution will nearly always be more elegant (small, simple maintainable).
I'm not saying that C++ is a bad language though. It just has a different purpose. It allows you to program OO if you want to and it allows you to program in a more traditional way if the OO thingies take a high performance hit.
Java on the other hand tries to take away the traditional performance hit of OO programming and thus allows to program in intuitive style.
First generation VM's did a lousy job at it. The current generation VM's actully makes this work on the server side and the next generation VM's will also make this work on simpler machines. (if your interested in this stuff check IBM's new VM and SUN's upcoming hotspot compiler, both beat the shit out of native compilers and MS fast but incompatible VM)
OMG now must have recognized this. Java is quickly becoming the programming language of choice on servers (mainly because of its scalability and ease of use, and yes it performs well too). Any succesful future CORBA implementation will have to support this language as much as possible otherwise Java developers will simply choose something else (RMI) and only use Corba to talk to legacy software (i.e. cobol, c an c++).
Greetings Jilles
Dylan faster? First-hand information. (Score:2)
AIUI, Dylan is a higher-level language that doesn't special-case primitive types and encourages slinging around closures and other powerful but hard-to-optimize idioms.
You're reasonably close. ;-) Dylan does allow some very powerful dynamic features which are a royal pain to optimize. (I spent last week crawling around inside a Dylan optimizer, so I know what I'm talking about.) However, these are all optional features--you can easily write very static programs which run fast.
Primitive types are handled specially in Dylan, but the language tries to be graceful about it. Just because integers show up in the class hiearchy doesn't mean that they're actually compiled that way. It's sort of like making 'int' and 'Int' into the same thing, and having the compiler use the more efficient representation whenever possible. It's actually pretty easy to get right.
Were they comparing a native Dylan compiler to a native Java compiler, or a portable Dylan bytecode interpreter to a JVM, or were they cooking their results?
Actually, the benchmark compared Harlequin Dylan to Microsoft Visual C++. It was run by a scientist who needed to do some number-crunching.
Harlequin Dylan finished within five percent of MSVC++. Gwydion Dylan (which I help maintain) wouldn't have done so well because it's still not finished. We usually see code that runs at half the speed of C.
All that said, there's no reason why Java should be any slower than Dylan. A good Java compiler should be able to match a C++ compiler for most tasks, which should amount to a three-way tie: C++, Dylan and Java, with some of the naive Dylan programmers paying a slight performance penalty by using excessively dynamic features.
Corba sadness (Score:1)
Compound Documents
Embedded Controls
Database connectivity (several tries, and none of them has supplanted ODBC)
COM/DCOM has a lot of holes (tossing binaries around the Internet to be executed is terminally stupid), but CORBA has taken way too long to support some of the same features.
C++ speed (Score:1)
Yes C++ has to run a destuctor, but the work that the destructor doesn't go away in java, you just have to find some other way to do the work.
As for freeing memory, if speed is an issue here, why not write a free operator for the class which does something like add the memory block to a list of memory that needs freeing and free it later when you have the time.
At least you can do that in C++, in java you have no choice but to do things the way that the system thinks is the best way.
(Not trying to complain about java, just saying that you can do just about anything in C++ that you can do in java with a bit of effort)
Basic Java issues that make it slower than C++ (Score:1)
All Java container classes' element manipulation is mutex protected. This is expensive.
This is no longer true with the Collections classes - they are a set of useful containers (vectors, maps, hash tables, linked lists, trees, and so on) that are not syncronized by default but also provide syncronized wrappers for the times you need them to be. The Collections package is built into Java2, but has also been availiable for the 1.1 JDK over a year (at least since the last JavaOne). Plus, there's also the free JGL if you want the equivilent of STL for Java.
In C++ you explicity control all object memory (warts and all). You may employ custom memory allocators that best fits the pattern of specific object usage often yielding huge speed gains. Or, more simply, create transient objects on the stack where appropriate and cleanup is practically non-existant. In C++ you simply have more control over what's going on in your program.
That all sounds very good until you have to maintain this carefully balanced cleanup code.
One of the reasons I like Java is that in theory you can just select better and better VM's with better ways to handle small temporary objects and ability to clean things properly, all without touching the code. I'm not saying that is fully realized yet, but it has proven true that over time the app I was working on had good solid improvements in performance as we migrated from VM to VM (eventually to 1.2 which had a great leap in UI performance).
Java has no notion of "const" which leads to the inefficient practice of creating a deep copy of often non-lightweight objects to return to the Java 3rd party library user "just in case". And no, garbage collection and "final" won't help you
here.
All I can say is, if you distrust your libraries so much that you have to hand it copies of objects, you need to re-think the libraries you are using!
In practice, the only time I've ever had to make deep copies of objects was in implementing a object transaction system, where you wanted an original copy of your object to roll back the changes.
If you want to provide a const level of safety I think a much better approach is taken by the Collections package - have a well defined interface into your object and the provide a read-only wrapper that throws exceptions when something attempts to modify the object.
The array access is probably still an issue, I think there may have been advances in that area by newer VM's but I can't say for sure.
Overall, I'd probably agree that C++ is still faster than Java - but as you can see many of the old arguments are being addressed and I think now the difference is close enough that Java is a very attractive choice for many projects (especially server side projects).
Heard Roger Sessions speak once... (Score:1)
Yeah, one person I know who went to a seminar
of his has the same viewpoint. Everything MS
all the time.
His article in the IEEE Software on Linux made
him sound like a drooling idiot. Some of his
other articles sound reasonable, but I'd really
hate to be dependent upon his mindset for
anything.
C++ is ALWAYS....No, not Always, Yes *ALWAYS* (Score:1)
If Java performs so much better in certain areas, why didn't you just code the C++ to do it that way???
I guarantee you that I can get a C++ program to run faster than any Java program, because ultimately if the C++ is slower, I'll just figure out how the Java code is implemented and the implement the C++ that way or better.
I will grant you that you might be able to get a Java program up and running quicker, but given enough effort, the C++ will be faster.
C++ is ALWAYS faster than Java... NOT! (Score:1)
seems not to have any idea about how modern
garbage collectors work.
C++ is not designed to use Garbage collection,
because the collector has no reliable way to find
out if something is a pointer or not. Therefore
only conservative, non-copying collectors can be
used with C++ unless one accepts very stringent
restrictions.
With modern GC's that have a copy phase the time for a GC cycle only depends on the on the number
of remaining objects. The garbage is just left behind. This clearly shows that the GC can be
faster than a simple straightforward C++ solution,
that depends on the number of objects allocated, which is usally much bigger.
Also keep in mind that the GC may run in an idle
phase of the application and therefore the response time that the user sees could be better than if the memory would be deallocated immediately.
ObjectWatch? A little biased maybe? (Score:4)
2. The OMG press release doesn't say what Mr. Sessions implies. It certainly doesn't say that vendor/language neutrality is being abandonded for the Component Model. It's basically just says EJB and CORBA work real good together. Read it for yourself here [omg.org]
3. And finally, from ObjectWatch's home page: "We specialize in offering training and
consulting on Microsoft's distributed component architectures"
Favorite post of the week (Score:1)
I've also suspected for a long time (as an outsider, I'm not a paid programmer but do some programming in the course of my work) that the real reason for a lot of these elaborate object-oriented schemes was to keep proprietary software viable. I think it's no accident that the proprietary world loves C++ while the free software world seems to prefer C. Many would agree that the data structure is the most important part of an algorithm, if you know the whole data structure (including function names), you can in many cases re-implement the algorithm. If you "hide" parts of it by making them private, it makes the task harder. It also makes it harder for you to tell if the algorithms are crap. CORBA, COM, and all that, seem to be a way to extend this stuff to distributed computing. I'll stick with things like Perl and Python for my "middleware" application glue. I also think you're right that standard, extensible data formats are more important than all this middleware stuff.
Not worth the trouble (Score:1)
>and XML...wherein the *DATA*, not code, is the
>medium of integration between applications and
>systems.
I think you're right on all points, especially the one item quoted above. All this thrashing about by the proprietary vendors will prove to be pointless after XML with XSL enters the game. The CORBA/COM debacle of these past years shows to anyone who is interested just what these vendors really want: Customers tied to proprietary product interacting with other proprietary product.
Fundamental computing/networking tools are too important to the future of our species for us to swollow these types of base, myopic decisions driven by quarterly returns: Get your profits from second tier applications, not first tier tools.
If a tool is not a sensical open standard which is readily used by anyone, then it is flawed and should be avoided. XML is a most sensical open standard readily used by anyone at the tool-building level as well as the application-building level.
is too... is not... is too... is not. (Score:1)
The practicality of implementing what Java has built in to it in C++ is laughable. I'm sorry but most software development houses don't have the time to re-invent the wheel.
Any true software developer would never say one language is ALWAYS better than another. Sure, they'll have a preference, but sometimes Java just makes more sense than C++.
Use the PL that makes sense. For some things, Prolog just kicks ass.
We should *not* be locked to one language (Score:2)
Do not confuse "Java the platform" with "Java the language". I can compile Java code to native machine-specific binaries if I choose, and get comparable performance to C++. When I compile for the JVM, then the result is the same but just for a different platform.
So... it locks you into Java no more than the COM spec locks you into C++ (it doesn't). I can write COM components in C, C++, Java, VB, etc. I just need to make the binary layout look right when dealing with interface pointers.
Isn't there an Eiffel compiler than generates Java p-code?
How does CORBA work... (Score:1)
Additionally, you should know the OMG process. OMG has no design/development staff - they issue RFPs, collect proposals, discuss them and eventually they ADOPT something, which needs to have at least prototypical implementation. EJB happened to be a great spec, it has existing implementations to proof that it works, so why not using it? All OMG need to do is additional work to map the same designs, interfaces and rules to the general environments/languages -- that's why the Component spec is bigger than the EJB spec. If OMG were dropping language independence, they would just adopt EJB as-is.
Only the uninformed developer, or the typical pointy-haired manager, will take this bullshit seriously.
Microsoft's Vision for Distributed Objects (Score:1)
That's the name of Roger Sessions' new book.
Is this REALLY losing language-independance? (Score:1)
The fact that OMG chose EJB as their implementation does not mean CORBA has lost its language independence. It's like saying that since OMG chose IIOP as their implementation of GIOP, that all CORBA applications are tied to IP networks. Which is bullocks.
Most people in this forum, and apparently the author of this article we're referring to, don't seem to have the foggiest clue about CORBA or the issues we're talking about. With a few exceptions of the people who actually made intelligent posts trying to explain the OMG specs.
As for CORBA being dead, well, those of you who have access to Gartner Group's reports can go dig up what they came up with their studies of nearly 500 major corporations. Seems to me DCOM has lots of catching up to do!
-- Jay
The reason why this spec is necessary (Score:1)
Sometimes I wonder why even bother teaching people to read. Most of them can't comprehend the sentences anyway.
-- Jay
Objectwatch is an M$ Consulting/Training Outfit (Score:1)
DON'T BELIEVE THIS HYPE (Score:1)
The death of CORBA is absurd. Due to the OMG's imperfect but democratic process, it is better now than it ever has been. This microsofty is announcing the death of CORBA due to the birth of EJB. Absurd.
Technically important, and strangely absent from the posting was the true relationship of EJB and CORBA. EJB does not replace CORBA at all! It is built on top of it. EJB uses RMI for distributed object communication, and RMI (and IIOP) have been enhanced so that the protocol of RMI IS IIOP. This means that an RMI client may make calls to a CORBA server, and vice versa.
CORBA
I hope they give up language neutrality... (Score:1)
By the way java is really inefficient at the actual status.
I think that could be a lot better if they use only object oriented languages instead that all languages (e.g. C++, Fortran 90, Ada 95 and so on)
And if they must choose just one object oriented language they could choose C++ that is far better than java about speed and diffusion among developers.
Bye,
Antonio
The reason why this spec is necessary (Score:1)
By the way this flame has been generated by an error inside the broad lines of the objectwatch article.
In fact they substain that the OMG choice imply a revolution about CORBA, the choice of Java as the only CORBA language.
Of course such gigantic error has been generated by their Microsof experience.
In their experience, I presume, there isn't any difference about source compatibility and binary compatibility.
Such ipothesis is reasonable if we think that the DCOM model is limited just to the x86 windows platform.
So they assumed that using Java for binary compatibility forces the CORBA users to use only Java and this assumption is so wrong that started our fury.
Goodbye,
Antonio
What about XMI (Score:1)