It Is a Bad Practice to Use Sun's Proprietary Java Classes

It is a bad practice to use Sun's proprietary Java classes?

Because they are internal APIs: they are subject to change in a undocumented or unsupported way and they are bound to a specific JRE/JDK (Sun in your case), limiting portability of your programs.

Try to avoid uses of such APIs, always prefer a public documented and specified class.

Classes from com.sun.* and sun.* packages should not be used Sonar issue for Jersey client

It's better to migrate to JAX-RS 2.0 client classes. Some refactoring would be necessary though. See the migration guide. For example, if you wrote like this before:

Client client = Client.create();
WebResource webResource = client.resource(restURL).path("myresource/{param}");
String result = webResource.pathParam("param", "value").get(String.class);

You should write now like this:

Client client = ClientFactory.newClient();
WebTarget target = client.target(restURL).path("myresource/{param}");
String result = target.pathParam("param", "value").get(String.class);

Usage of sun.* is discouraged

It's stated pretty clearly in the documentation your linked :

A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.

So end-users might not be able to use your app if they're not using the same JDK as you.

And yes, in the future you might have problems too with a newer version of your JDK.

Cannot Import sun.net.*

Quote from Oracle:

A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.

To solve the issue, you will have to find the alternative to each missing class and replace it.

Source:
Why Developers Should Not Write Programs That Call 'sun' Packages

Using internal sun classes with javac

I have found the answer myself.

When javac is compiling code it doesn't link against rt.jar by default.
Instead it uses special symbol file lib/ct.sym with class stubs.

Surprisingly this file contains many but not all of internal sun classes.
In my case one of those more-internal-than-usual classes was sun.awt.event.IgnorePaintEvent.

And the answer to my question is: javac -XDignore.symbol.file

That's what javac uses for compiling rt.jar.

with JDK 1.8, unable to extend WToolkit class

Yes the class WToolkit is final in java 8:

 public final class WToolkit extends SunToolkit implements Runnable {

See the implementation.



Related Topics



Leave a reply



Submit