The Eclipse Java compiler issues an inappropriate warning in the following code:
public int zot(Object obj) {
if (obj instanceof String) return 1;
if (obj == null) return 2; // inappropriate warning on this line
return 3;
}It complains that obj cannot possibly be null -- even though it can. Experimentation suggests that something about the instanceof operator confuses the compiler.
The Eclipse Java compiler does some clever reasoning about the possible null state of variables. For example, the following code will compile without complaint:
Object result = getMyObject();
result.doSomething();
However, the compiler will generate a warning that result may be null in the following:
Object result = getMyObject();
System.out.println(null == result);
result.doSomething(); // warning: result may be null
The two look the same semantically, don't they? It would appear that the compiler, as an expediency, presumes that any object returned from a call will be non-null, until it sees evidence that there is any other possibility. In the second instance, there is such evidence because the programmer has expressed concern explicitly. A clever trick, to be sure.
You must take care when implementing Object.equals() for Java objects being persisted using Hibernate. Well, this is no surprise because the Hibernate documentation says so. However, here is a subtle gotcha that is not emphasized in the current Hibernate documentation. I ran across some classes whose equals() method tested that the other object was of exactly the same class as the target object. This is unusual, because most equals() methods settle for instanceof. The ones that used strict equality were broken because Hibernate's decorated versions of classes might be used in place of the actual classes. Consider, for example this stack trace:
TBProductCatg(AbstractPersistentObject).equals(Object)
AbstractPersistentObject$$FastClassByCGLIB$$1ce0f1a2.invoke(int, Object, Object[])
MethodProxy.invoke(Object, Object[])
CGLIBLazyInitializer.intercept(Object, Method, Object[], MethodProxy)
TBProductCatg$$EnhancerByCGLIB$$ec0e8df4.equals(Object)
In this case, the initial call to equals() was passed a decorated object but you can see from the trace that it ultimately was passed to an undecorated version of the class.
As of IE7, any URL whose host portion contains a dot is considered to be outside the intranet zone. Thus, automatic Windows authentication is disabled (by default). As a workaround, you can now add individual URLs to the list of intranet sites.
I tried to add a wildcard for the local domain to the list of sites (*.mm.local). IE complained that the URL was already listed in another zone, and that I should remove it from that zone first. True enough, it was in the trusted sites zone. So I removed it and tried again. I exited and relaunched IE. I logged out and logged back in. I rebooted. The same message occurred after each of these measures. I tried a different wildcard, and it worked.
There appears to be a bug where once something has been in the trusted sites zone, you can't ever add it to another zone. I connected to a web site in the local domain, entered the requested password, and IE showed the site as still belonging to trusted sites. But the wildcard no longer appears in the trusted sites list.
Problem solved. The registry key
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
contains the IE zone mapping. It didn't show my local domain, but the corresponding key under HKLM did. I'm not sure how the HKLM key got there, and there was no evidence of the registry setting in the IE configuration dialogs. Deleting the key made things work as expected.