> And b) Java libraries today are implemented by the same people that > yesterday coded that C++ library. Don't expect miracles. You misunderstand me. Many C++ libraries are not thread safe by design - not because of bugs. The C++ community has not embraced threads to the degree that the Java community has. I don't imply the C++ community isn't justified in its decision. I just mean that because of the decision, its harder to write a threaded C++ application than a threaded Java application. Try it sometime, write a threaded C++ application with a certain compiler on a certain platform using a mix of 3rd party libraries. If that isn't challenge enough for you, then port the application to a different compiler on a different OS. Then repeat this with process with Java. > Please do not give/take Microsoft as a source of good code > quality and standards. I mention Microsoft simply because they have produced a large amount of C++ code that is used extensively in the world and because my lastest project involves DirectX (a C++ library by Microsoft). Much non-microsoft C++ code is not any better. In my experience most C++ developers ignore the modern best practices, idioms, styles, and design patterns illustrated in the trade journals (e.g. C++ Report). It's easy to see C++'s C legacy. > > Vendor lock is something Java hopes to fix. > > Hmm.... Read your sentence aloud until the problem is obvious. If > not, scroll.. Yes, Java is controlled by Sun, but at least there are multiple Java compilers, virtual machines, and J2EE environments to choose from that all work together relatively well - at least in my experience. [MS's JVM is a major exception to this, but that is a moot point now.] This is not as true of C++ where you can easily get tied to one compiler and one operating system. Porting to another compiler/OS is generally a major task. I've had the mispleasure of doing it more than once. Even porting between supposedly POSIX compliant OS's can be a major task. Mike