From: Tor Iver Wilhelmsen Date: 2006-07-08T01:20:13+09:00 Subject: Re: Grails The Ghost In The Machine writes: > [W] int vs. Integer, float vs. Float, boolean vs. Boolean. Boxing helps > but is a band-aid. C# got autoboxing around the same time as Java. > [?] Are the non-byte datatypes fixed-size? Yes; a char is ALWAYS unsigned 16 bits, an int is ALWAYS signed 32 bits amd a long is ALWAYS signed 64 bits. float and double also have set sizes. > [P] The Enumerator/Iterator dichotomy doesn't look necessary. I never understood why Sun half-assed introduced some patterns to early Java (Observer and Iterator in particular) - and then managed to call their Iterator class Enumerator instead. > [W] AWT and Swing work well enough together but do we really need both? Swing builds on AWT. The former feels half-assed, and to do much you end up using the primitice stuff like Graphics anyway, which is what Swing basically does: It renders in the Graphics of one of the root peers. > [W] [].length vs. String.length() vs. Collection.size(). Can we > clean this up? Nope. > [W] a.equals(b) requires that a be non-null. Clarification: "object-reference dot-operator something" requires object-reference to be non-null since it's the type of the object that defines what exact method is called. Without an object there is no way to know - and code is easier to write if an instance method can be certain "this" is non-null. > [W] "".equals(null) returns false. Granted, maybe they're supposed > to be unequal, but one wonders if there shouldn't be an > equalsNullIsEmpty(), at least, ugly as that is. Most people ensure > Strings are non-null so this isn't that big a deal but it is > annoying. An empty String and null are distinct. That you want to equate them is not the language's problem (which defines a very narrow role for null); You want special semantics, you need to code them yourself. > [W] Various protocols in J2EE assume a mapping of xzy -> getXyz, setXyz. Yes, that's the JavaBean specification. > Unfortunately, class is a reserved keyword, although getClass() exists. Why would you ever want to use getClass() for something else? It has a particular meaning in the language. > In a way, that's good news, as that means getClass() isn't available > for the casual user and he would have to use things such as > getDefiningClass(), getClazz(), or other such junk. In a context where you want a property called "class", use an alias like "course", "socialLadderRung" or whatever. :) > [?] I'm not sure about catching run-time exceptions such as > NullPointerException and IllegalArgumentException. It's convenient > to catch them, of course, print the traceback, and keep the app from > dying. However, it also is probably being misused. How to prevent > this, I for one don't know; I doubt C# has a much better solution > here, and I certainly do not. C#'s "solution" is to make all exceptions RuntimeExceptions. :P For NPE, you really should test for null instead. > [P] java.io.Serializable should have generated XML from the > beginning. No, because a binary representation is more compact. > Of course there's the little issue of timing; > I don't think Java, in its alpha stages, knew about XML. It wasn't as popular back then compared with e.g. EDIFACT > Ditto for java.rmi. Remember this was made by Sun, the people who brought you RPC. > [P] It is possible that Java.io.File et al could have avoided some > silliness by pathname translation -- in other words, '/' is always > the path delimiter, and there is only one root, so that G: would be > mapped to, say, /g. Then you would need a) to have a to-from mapping layer and b) train platform developers to write paths in a different manner than they're used to. What's needed is for Windows programmers to learn that they can use forward slashes. And old MacOS is dead. :) > [M] The "webbrowser" of javax.swing.JEditorPane has many problems. That's because (as I understand it) it was made simple (understanding only HTML 2.0 and CSS 1.0) intentionally, so as not to ruin the market for developers who wanted to make more heavyweight components (like ICEBrowser). Of course, the component market largely died out as Swing got a bad reputation (undeserved, as any user of Swing-based Borland JBuilder can attest) and people for some reasoun started making web applications instead. > [M] A PDF Swing viewer would be nice. There might actually > be one, but if so I'd have to find it; it's not part of > Java currently. RTF, strangely enough, is. Adobe made a Java-based PDF viewer: http://www.adobe.com/products/acrviewer/acrvdnld.html > [M] Built-in support for ASN.1 would be nice as well. Admittedly, > ASN.1 has apparently been relegated to "just for SNMP traps", > despite the fact that ASN.1 can in theory replace RMI entirely, much > like SOAP. Watch this space. ASN.1 is one of those binary formats that grew out of ISO. It's lack of popularity can perhaps be attributed to the lack of popularity for other ISO things like X.400 (ISO MOTIS) mail. > [P] Is there a good reason why Runnable.run() can't throw a > Throwable? (Apart from the perhaps obvious one of trying to > disentangle Throwables in the calling thread, which are not thrown > by the calling thread?) Well, it would end up in the ThreadGroup's uncaughtException() method, but who here actually use ThreadGroups and that method for anything? > [P] ThreadLocals are interesting. Are there better methods by which > a Thread can have its own value of certain statics? For example, a > Thread might extend Comparable, allowing Threads to be put into the > key side of a Map. Of course the user could implement that himself, > but this is a little weird. The problem is that Threads have a very specific purpose, and should stick to their designated role, and not become general-purpose objects. That's for the object implementing Runnable (that the Thread manages) to do. > [?] Is java.lang.ThreadDeath going away anytime soon, > since the only method causing it is deprecated? Deprecated items just rot and stink, they never go away. Backward compatibility for the win!