Is it safe to use Java private methods (JDK class)?

Question

We used a private method, through reflection, of a JDK class. Is there a guarantee this will not change in a future release ? what is the QoS of a private method for a JDK class ?

We used ThreadPoolExecutor.isStopped() which is actually missing in Java 6 v18. Is there an easy way knowing the minimum jdk required or how to check when a class is changing in Java?

Comments are welcomed and yes we know better not using private methods :-)

Answer 1

There is a reason those methods are private, despite belonging in a public class: they are considered to be part of the implementation, rather than part of the interface.

You should not use private members of the Java implementation classes - they probably do not exist in JVM implementations from other vendors and can easily disappear from the next version of your current JVM with no warning or notice. For all you know, they might even be absent from the implementation of the same JVM in another platform.

The only case where I can justify using something like that is for development-related code that will be removed/disabled in a production system - e.g. using the HotSpotDiagnosticMXBean class to perform a heap dump at will. Code like this, however, should never be used on a production system - it removes the advantage of portability that Java is supposedly used for.

Answer 2

We used a private method, through reflection, of a JDK class.

The method is package-private.

Is there a guarantee this will not change in a future release ?

There is no guarantee the method exists in previous releases or on other platforms. e.g. it might work on all versions from OpenJDK but not IBM or JRocket.

what is the QoS of a private method for a JDK class ?

None. You have to assume it may or may not work with a different version.

We used ThreadPoolExecutor.isStopped() which is actually missing in Java 6 v18. Is there an easy way knowing the minimum jdk required or how to check when a class is changing in Java?

You can check whether the method exists by trying to use it. It is possible, but unlikely, the purpose of the method could change. There is no simple way to check for this.

Answer 3

The public API defines the methods through which you can interact with objects. A good public API (and Java's is) will deprecate methods over time giving you a chance to upgrade your code to make use of the new and improved API. Often 'deprecated' methods will remain in the API for many releases, to provide backward compatibility.

This is not true of private methods, which could disappear in a minor update and no guarantees are made about their presence (or even the way they will operate). It sounds like an improper use of reflection, and indicates that you may want to create your own implementation of the functionality to guarantee it will be there in the future.

Answer 4

It is by no means safe to assume that a method that is not publicly available will never change. Private methods are part of the implementation of the class, and they may change or be removed in any way between releases. You should never depend on such a method, ever.

ThreadPoolExecutor has two methods isShutdown and isTerminated. Why don't you use one of them instead?

Answer 5

We used a private method, through reflection, of a JDK class.

Very bad idea.

Is there a guarantee this will not change in a future release ?

No. It may change or disappear in any minor release.

what is the QoS of a private method for a JDK class ?

If there were a service-level agreement involved here, you would have forfeited it by using reflection to access a method you should not.

yes we know better not using private methods :-)

No, apparently you don't.

Why don't you use isTerminated() or isTerminating(). From the API doc it seems that one of these should do what you need.