Java class name same as the nested package name

Question

In my Java application, I use a third-party library.

However, I found something strange, there are some nested packages, and some classes whose name may be the same as the name of the package.

I am afraid I can not make it clear. Here is an example:

package

  com.xx.a
  com.xx.a.a

And there is a class named 'a' inside the 'com.xx.a'.

So if I want to call this class 'a'...

I write:

a ma = new com.xx.a.a();

Then the IDE will think that I mean the package 'com.xx.a.a'.

Then I can not call it.

I wonder why?

By the way, it seems that the library provider did not want us to use these kinds of classes.

How do they do this?

Answer 1

You need to do this:

com.xx.a.a ma = new com.xx.a.a();

Or import the package:

import com.xx.a;

a ma = new a();

Answer 2

The Java language allows class identifiers to be obscured by package identifiers. In your case the class com.xx.a is obscured by the package com.xx.a.

From the Java Language Specification:

6.3.2 Obscured Declarations

A simple name may occur in contexts where it may potentially be interpreted as the name of a variable, a type or a package. In these situations, the rules of §6.5 specify that a variable will be chosen in preference to a type, and that a type will be chosen in preference to a package. Thus, it may sometimes be impossible to refer to a visible type or package declaration via its simple name. We say that such a declaration is obscured.

I must say that the rules in §6.5 for classifying the meaning of an identifier are far from clear though.

The reason why you still happen to have a copy of a library that violates this rule is because the rule does not apply for class files / JAR files and the JVM.

This means that you can have such naming conflicts in JAR files, but you'll never see it as output from javac. The tool that has produced these class / package names is most likely a code obfuscator which produces this kind of messy code to compress the size of the files and to obfuscate the code to prevent reverse engineering.

---

PS. At a closer look it may actually be a bug on the Eclipse side (assuming that's the IDE you're talking about). By letting an empty package name collide with a class name, Eclipse chokes on something javac accepts. The spec is hard to follow, but from what I can see, javac follows the spec in this case.

Answer 3

Sometimes you want to access the package and not the class. But the order for the compiler is variable type package. I had to rename all the packages, classes and variables.

For example: int a would become int a_var class a would become class a_class package package a would become a_package

I used eclipse refactoring functions for this.

You still have to go through the classes and rename all conflicts by appending _var, _class or _package. Hard work, but since there is no way for Eclipse to know by usage(String a.a.b.c, import a.b.c.d) he will still try to find first variable/type even when it is a package.

Answer 4

The library is likely obfuscated (e.g. using proguard) to reduce size, prevent reverse engineering and "hide" stuff you're not supposed to use. Even if you manage to create an instance of this class, I would recommend against it, as you don't know what it will do or how it can/should be used.

Answer 5

we can not do this in java:

com.xx.A
com.xx.A.yy

the package name clashes with a class in the parent package,.