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

Answer 1

This is a common issue when decompiling jars. The Compiler will get confused when there is a class and a subpackage with the same name. If you don't find a compiler with the option to append a prefix regarding the type(package, class variable) you have to refactor the source files. You can do that with regex by for example renaming every package declaration and import from import A.B.C to something like import pkgA.pkgB.C. Of course you can't do that for the external packages from the sdk or other libraries but most of the time the used obfuscator renames them in the same way so for renaming to letters from A-Z you could use something like:

RegexFindAll("import\s+(?:[A-Z]\s*.\s*)*([A-Z])\s*.\s*(?:[A-Z]\s*.\s*)*[A-Z]\s*;")

RegexFindAll("package\s+(?:([A-Z])\s*.\s*)*([A-Z])\s*;")

And from there on you can rename every package. If your IDE doesn't offer such functionality you can also rely on the terminal with following commands.

To find all the files by name recursively(extendable with filename filter)

find -follow from https://stackoverflow.com/a/105249/4560817

To iterate over the found filenames

sudo find . -name *.mp3 |
while read filename
do
    echo "$filename"    # ... or any other command using $filename
done

from https://stackoverflow.com/a/9391044/4560817

To replace text inside a file with regex

sed -i 's/original/new/g' file.txt from https://askubuntu.com/a/20416

Answer 2

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,.

Answer 3

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 4

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 5

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.