Paul G. Allen wrote: > Christopher Smith wrote: >> Java lacks from that list: >> 1) overloaded operators > > OK, you got me there. I missed "operators" and threw in methods. :) > (but as Stewart pointed out, this is a good thing)
I wasn't debating whether it was a good thing. In general these are trade offs. My point was that this feature, along with the others I mentioned, allows for a unique capability that is nice to have. >> 2) access to platform specific features (yes, you can use JNI but at >> that point you aren't using Java) > > Well, aside from JNI, there's the example of the COMM API and SerialIO > API. There's also Java extensions allowing access to platform specific > features. Umm.... no. these are API's provided by Java, through JNI. >> 3) destructors, and lexically scoped resource management in general > > Yes, Java does. Look up finalize() for a destructor of an object. Finalizers are not destructors, and arguably actually have more problems than destructors. > There are also ways to manage garbage collection outside of the automagical > way Java normally handles it. Also look at java.lang.management (Java > 1.5) for another way to handle resource management. Sigh. Everyone seems to think that the only resource one might want to manage is memory. Basically java.lang.management gives you a few small knobs for memory management and a few ways to monitor use of a couple of other specific resources. In the area of resource management Java is a fork with one tine (actually, I'll give it provides nearly as good 90% case support for synchronization resources). >> 4) multiple inheritence > > Java does provide for it. It is awkward to implement, but can be done > through the use of interfaces and mixin classes. It is also very rarely > needed. It's rarely *used*, not rarely *needed*. The hacks for doing mixins in Java (even with generics) don't allow you to do policy based design. Thank you, type erasure. >> 5) fairly well defined performance costs > New profilers, tools, etc. for J2E have allowed much better methods of > defining performance costs. No, they have allowed much better methods for discovering performance costs. That is an entirely different matter. >> On top of that, it's support for generic programming is limited enough >> that it's hard to use it effectively outside the context of collections. > > I have not found it hard to use at all. In fact, I've found it much > easier than C++. Java's generics are much easier to use than C++'s templates. They are, unfortunately, quite limited. >> So no, I didn't describe Java. > Damn near. If you can show me how to do policy based resource management in Java (i.e. no "finally" blocks in the application code), I might agree with you. Otherwise, arguments that Java is "better" than C++ are kind of irrelevant to whether Java has this capability. --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
