What is the difference between sun.reflect.generics.reflectiveObjects.NotImplementedException and org.apache.commons.lang3.NotImplementedException

Question

I have discovered there are 2 NotImplementedException:

• sun.reflect.generics.reflectiveObjects.NotImplementedException
• org.apache.commons.lang3.NotImplementedException

Since there is not an available documentation for the first one, I'm not able to understand the difference between them. What is this difference? Is one of them better than the other one?

Answer 1

I have discovered there are 2 NotImplementedException

I found more examples than that. It depends on how hard you look ... and where.

---

Since there is not an available documentation for the first one ...

That is because sun.reflect.generics.reflectiveObjects.NotImplementedException is an internal class. The source code says:

"Temporary class used to indicate missing functionality"

---

What is this difference?

They both mean the same thing, more or less. Some piece of functionality has not been implemented.

---

Is one of them better than the other one?

I assume that you are really asking whether you can and should reuse either of these exceptions in your code.

1. Since the sun.reflect... exception is an internal class (see @GhostCat's answer), it is inadvisable to use it in your code. There is a chance that the class will "go away" in a future release of Java¹. That will present problems for your codebase.

2. It is reasonable to reuse the org.apache.commons... exception. Indeed, my reading of the javadoc, it is designed to be generally reusable. However:

   • It is not standard.
   • In fact, there are at least two versions of this class, in org.apache.commons.lang and org.apache.commons.lang3. (See bullet #1!)
   • You would be (potentially) be adding a new dependency on Apache Commons. That could increase your maintenance costs; e.g. if someone were to find security issues in Apache Commons that required patching. Also, if your company has anti-opensource management or lawyers ... the effort in getting them to grant an exception to a corporate "no opensource" policy might be too much.

3. The other alternatives are to declare your own custom exception, or simply use the existing java.lang.UnsupportedOperationException ... which is standard, doesn't add a new dependency, and won't be removed in a future Java release.

---

^{1. I'm not sure of this, but I think that access to sun.reflect.generics.reflectiveObjects is blocked in Java 9.}

Answer 2

I can answer with this. What is the difference between com.your.package.NotImplementedException and org.apache.commons.lang3.NotImplementedException?

The sun.reflect.generics.reflectiveObjects.NotImplementedException is JDK internal API, not for usage in user code.

Answer 3

It is pretty simple: anything that lives in a package starting sun... is (almost always) safe to ignore (there are some rare exceptions, like sun.misc.Unsafe)

In other words: these packages that still come with the JDK/JRE are not meant for public usage. Even when they provide something useful - you better look out for "really public" alternatives. The main purpose of such classes is to help implementing "internals" of the JVM. They are completely out of your control, and there are almost no "guarantees" whatsoever what happens to them over time.

In that sense the answer is: that sun exception is one that you simply should not use; whereas the apache commons one might be a good candidate. The whole point of the commons classes is to be used "publicly".