The type checker maintains a table of all types encountered during checking which indexes class types under both the package qualified name for a type (where known) and it's non-package qualified ('short') name, the latter as an alias for the former. So, for example, on encountering type name Foo and finding that it refers to class org.my.Foo the type checker install a primary type with name org.my.Foo which is associated with the corresponding Java class but also installs an alias type with name Foo that indirectly references the primary type. All type operations derefence alias links before performing type checks. This frequently allows references to types by name to omit the package qualifier – Byteman infers the correct full name from context.

Currently, this causes a problem when the type checker encounters two distinct types with the same short name. For example, a rule with class specifier

CLASS ^java.net.HttpURLConnection

may be injected into class sun.net.www.protocol.http.HttpURLConnection. The latter name is entered into the type table as the type of $this. However, during type checking the checker may encounter the former name as e.g. the return type of a method call. The present code finds that the short name is already in use and so fails to add the second type to the table returning null as the type of the associated rule element (e.g. a MethodExpression). This null return is not checked for and eventually this leads to a NullPointerException.

It would be rather limiting simply to provide the missing null checks and fail type check in the presence of such a name clash. However, the altrenative of dropping the use of short names is also not attractive The preferred strategy is to provide a short name alias for the first version of a type that is encountered while simply installing the fully qualified name for secondary occurrences. This runs a small risk that the rule creator might get the wrong variant of a type in the rare circumstance where ambiguity arises e.g. a mention of HttpURLConnection in a rule with the cited class declaration would actually end up referring to the class in the sun.* package rather than the java.net version. IN practice this is not likely to be a great problem.