What Is Inside Com.Sun Package

What is inside com.sun package?

It contains Sun Oracle reference implementations of the standard Java (EE) APIs. Among others Mojarra (the reference JSF implementation of Oracle) and Glassfish (the reference Java EE implementation of Oracle) use this package. It's preferable to not use those classes directly in your code as it would make your code tight coupled to the implementation. Coding against the java(x) API directly enables you to change the implementation without changing your code (e.g. MyFaces instead of Mojarra and JBoss AS instead of Glassfish). Also JDK's own HttpServer sits in the com.sun.* package, see Simple HTTP server in Java using only Java SE API.

Please note that the com.sun.* package should not be confused with sun.* package which are the internal classes behind Oracle JRE which you should absolutely not import/use in your code as it would make your code tight coupled to the JRE make/version. Not using sun.* package at all enables you to run your code on all other JRE implementations (OpenJDK, GCJ, etc).

Difference between sun.* vs com.sun.*

Some com.sun.* classes are actual external API and may be used. The key is to check the official Javadoc to see if the classes you want to use are listed as API, and not marked @Deprecated or anything of that sort.

Here is the official javadoc page to check at:
https://docs.oracle.com/en/java/javase/11/docs/api/index.html

In general, sun.* API refers to some of the oldest Java APIs (such as sun.misc.Unsafe) which predate the reverse-DNS package naming convention. Most of the original sun.* APIs have either been removed, promoted to official javax.* API, or renamed to the more proper com.sun.* domain.

There is nothing inherently wrong with using com.sun.* APIs, provided the API is not a JDK internal or marked for deprecation/removal.

What does com.sun.el package contain?

It contains Sun's implementation of the javax.el API which is specified by EL specification. This API is part of Java EE, not Java SE. Implementors are required to provide a concrete implementation of the abstract API so that all the API-definied works will be done. Java EE is basically one large abstract specification. The servletcontainers / applicationservers like Weblogic, Tomcat, Glassfish, etc offers the concrete implementations.

As to your actual problem, no, you indeed can't concatenate strings in EL using + operator like that. The + operator in EL assumes the both sides to be a Number, for round numbers that's Long. That's specified in the EL specification.

You can however just use multiple expressions like follows to "concat" strings.

<h:outputText value="#{user.firstName} #{user.lastName}" />

do not use com.sun.xml.internal.*?

Sun classes in the JDK are prefixed sun.* and are not part of the public supported interface so should be used with care. From the Sun FAQ:

The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java., javax.,
org.* and sun.. All but the sun.
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun., that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.
packages are not 100% Pure Java. In
other words:

The java., javax. and org.* packages
documented in the Java 2 Platform
Standard Edition API Specification
make up the official, supported,
public interface.

If a Java program directly calls only
API in these packages, it will operate
on all Java-compatible platforms,
regardless of the underlying OS
platform.

The sun.* packages are not part of the
supported, public interface.

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.

Sun's Java Package Naming Convention: sun vs. com.sun

The "com.sun" convention is the more preferable format because it follows the "naming conventions" that have been established for naming Java packages.

http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html

You're supposed to use your unique company or personal website URL as the first few words in the package to guarantee uniqueness in the namespace. The ones that start with "sun" were probably not intended to be exposed to the outside world.

SonarQube rule Classes from com.sun.* and sun.* packages should not be used

That's a bug in SonarQube. It's overgeneralizing the sun.* package as mentioned in Why Developers Should Not Write Programs That Call 'sun' Packages to com.sun.* package. This is incorrect. Oracle didn't mean to say that in abovelinked article. SonarQube should really only penalize usage of sun.* package or whatever is internally used by an arbitrary JRE/JDK implementation. The com.sun.* package is not JRE/JDK API/impl related at all.

Either turn off the S1191 rule, or mark all hits on com.sun.* as false positive.

See also:

• What is inside com.sun package?
• SonarJava issue 437

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);

---

Related Topics