Home > front end >  package com.sun.beans.finder does not exist openjdk
package com.sun.beans.finder does not exist openjdk

Time:02-08

When a file is compiled that imports com.sun.beans.finder.ConstructorFinder, this error comes out:

./src/Demo/FeatConstruction.java:14: error: package com.sun.beans.finder does not exist

The system is an Ubuntu 18.04.1 with OpenJDK:

openjdk version "1.8.0_322"
OpenJDK Runtime Environment (build 1.8.0_322-b06)

Where can I find this package?

The compilation process is as follows:

  • Sources files are located in src
  • Some jar dependencies are in lib
  • The output classes are in bin

For ./src/Demo/FeatConstruction.java, I compile it using:

javac -cp "./src:./lib" -d bin ./src/Demo/FeatConstruction.java

CodePudding user response:

I found a trace of these classes here: https://www.programcreek.com/java-api-examples/docs/?api=com.sun.beans.finder.ClassFinder

From the package name I'd conclude they come from the times when Sun owned the Java stuff and thus are at most to be found in Oracle JDK - but not as the standard classes.

To lookup classes, you may want to switch to the standardized API. For any Object (or derived class instance), run

Class objectClass = Class.forName("java.lang.Object");

With that you can also find classes by name and get class references back - and it is available on all Java implementations.

CodePudding user response:

First of all, you shouldn't be trying to use this class in your code. It is an internal class. All classes in com.sun.* are notionally internal, and should not be used directly in your code.

The class exists in the OpenJDK codebase (Java 8, 11 and even 17), and is present in rt.jar in the OpenJDK Java 8 installation on my Ubuntu box.

But even so, my Java 8 javac is still saying that the package does not exist. So I suspect that javac itself is black-listing the package.

There might be a workaround1 for this, but my advice is DON'T DO IT. Find another way to implement the functionality rather than relying on some undocumented internal class. For example, look for a well written2 3rd-party library.

If you do find a way to make your code compile and run on Java 8, be aware that it is liable to stop working on later releases. 1) The class may be renamed or removed without notice. 2) In later versions, they are making it harder and harder to directly use JDK internal classes in your code.

If you persist with this bad practice you are stacking up future problems for yourself ... or the poor mug who has to maintain your code.


1 - ... but I doubt that switching to an Oracle Java 8 distro is going to help.
2 - A library that doesn't do this kind of bad stuff under the covers.

  •  Tags:  
  • Related