From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: "Erik Funkenbusch" Subject: Re: Ada vs C++ vs Java Date: 1999/01/14 Message-ID: X-Deja-AN: 432610863 References: <369C1F31.AE5AF7EF@concentric.net> <369DF242.B0613E1C@no-spam-ibm.net> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 X-Complaints-To: abuse@visi.com X-Trace: ptah.visi.com 916336047 209.32.179.125 (Thu, 14 Jan 1999 11:47:27 CDT) X-MSMail-Priority: Normal NNTP-Posting-Date: Thu, 14 Jan 1999 11:47:27 CDT Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.java.advocacy,comp.realtime,comp.arch.embedded,comp.object,comp.lang.java.programmer Date: 1999-01-14T00:00:00+00:00 List-Id: Michael J. Tobler wrote in message news:369DF242.B0613E1C@no-spam-ibm.net... >Erik Funkenbusch wrote: >> All three do, although at differing levels and differing feature sets >> (example: Java doesn't support Multiple Inheritance, C++ does. But that >> may not be a concern to you). > >Java does support multiple-interfaces, so there is a sort of >"simulation" of multiple inheritance. But there are reasons >the designers opted not to provide "true" MI, reasons I wont >go into in this thread. I wasn't criticizing Java over this. I was simply stating the fact that there are differing levels of OO features in the different languages. Don't be so sensitive just because I used Java as an example. I could have just as easily said that C++ doesn't provide the flexibility of Java with nested classes. >> Be aware that "safe" often means "confining". You may not be able to do the >> things you need to do in a language that doesn't support pointers or direct >> hardware access (like Java). > >I think here it's meant that you cant do anything "crazy" >and have some wild pointer or what-not. The OS should take >care of this for you; yet, there are reasons you might >want a language to help you in this respect. Say, something >like handling array-out-of-bounds, etc. Which doesn't change the point that "safe" languages do not allow some things which are necessary to do certain things. For instance, you can't use Java to point to a memory mapped I/O structure. C++ can (because it allows pointers). >> Well, Java is gaining a lot of vendor support. But be aware that the >> language is changing rapidly and that there is no standardization of it. >> New versions are likely to make older code obsolete (for instance, the >> switch from 1.0.x to 1.1 introduced whole new event models). It's a very >> immature language and is likely to go through a lot more growing pains. > >This is a mistake that a lot of people are making. The JDK is >changing rapidly - I dont necessarily see this as a hinder as >more functionality is coming to the forefront. The LANGUAGE proper >hasnt really changed. Hey - there's something to be said for a >language that doesnt support "goto". The problem is that you can't differentiate the language from the environment in Java. If the environment changes, so must your programs. Whole features of Java have been deprecated and will be going away in future versions. The point is that this kind of change is not good for a long term project that must rely on the code to continue functioning. What's worse with Java is that since it's a run-time language. If the JVM changes, existing compiled code will no longer work. WIth a compiled language the already compiled code continues to function no matter what changes occur in the language. In other words, it's very likely that you won't be able to use Java 1.0 byte code with Java 3.0 byte code. >> Processors aren't the key, OS platforms are. You're most safe with C++ on >> this matter i think. Java isn't available on everything yet. You're also >> likely to find limited choices in ADA compilers on more obscure OS's. > >You cant say C++ is "more safe" in this matter. It depends how the >system is designed and coded. I can write a program targeted for the >unix platform that will pure h@ll to port anywhere else. It is harder >to do this in Java. BTW, I build a lot of C++/Java/CORBA systems and >haven't found a platform that didnt run Java. Yea, maybe some obscure >platform .... I didn't use safe in the same way you are. I said "most safe with C__ *ON THIS MATTER*". This simply means that C/C++ compilers are more common than either Ada or JVM's. Never found a platform that doesn't run Java? How about BeOS? How about WindowsCE? How about Real-time operating systems? How about a standard embeded processor without any OS? The point is that "some obscure platform" is the most likely going to be the target platform for an embedded system. >> C++ generally isn't. There is an "embedded C++" that's in the works, and >> there might even be some implementations. C is better for embedded work >> than C++. I don't know the specifics of ADA embedded work. > >You're off-target here. There are a handfull of vendors offering >C++ tools for the embedded systems market. Saying that C is better >than C++ is just not valid. Better meaning "more availability". A "handful" of vendors is very different from hundreds of implementations. The fact is, apart from assembler, C is the most common langauge used in embedded systems. There are far more C compilers for embedded systems than anythign else. C++ also tends to generate large code. That's not good for embedded applications where you have maybe 4K of ROM. Embedded is getting much bigger today, and C++ will certainly be easier to use in today's embedded applications than yesterday's. >> Well, I would vote against Java. It's too immature for a long term project >> and has questionable speed. > >I think you should educate yourself concerning Java. As I've said, >we've been building Java (collaborative, multi-tier) systems for >about 3 years now and the customers are very happy. I am currently >on a C++/Java/CORBA project that is 90% Java and 10% C++. The coding >is going VERY fast - I find that we can code a system much faster, >with less errors in Java than in C++. I'm not knocking C++ because >it's my TRUE language, but I have found power in Java. And? You seem adept at diverting the point. The point is that Java is an immature platform and language. It's changing rapidly, and it's likely to change a lot more before it settles down. C++ was in that stage until the last few years, and C++ is more than 15 years old. 3 years is nothing. Java has a *LOT* more growth ahead of it, and a lot of it will be painful. Standardization will take at least another 3-5 years and the ISO committees will demand that a lot of things change. >To address you concern for speed with Java - that issue >is out the door. We are using JIT tools that get us to >C++ like speed. Depending on platform, you can get tools >to build true binary executables. JIT doesn't cut it when you're talking about real-time (or near real-time as required in this case) processing. I'm sorry, but an aircraft avionics system cannot wait while the subroutine it needs to use compiles and loads. Speed of execution is not the only factor of how fast a system runs and how acceptable the delays introduced by the system are. Even Native compilers for Java do not produce equivelant code to native C or C++ code (only in certain circumstances of very poor C++ and very good java do they compare).