3

I'm trying to upgrade a legacy Java EE application to Jakarta EE 8 on a Wildfly server. Most of the upgrade has gone smoothly since 8 doesn't swap the package names to jakarta yet. However, some of our code is using classes from Oracle's com.sun.faces package. These classes appear to be included in the Jakarta EE Faces API specification, but they are not included in our project when I use the following Maven dependency:

<dependency>
    <groupId>jakarta.faces</groupId>
    <artifactId>jakarta.faces-api</artifactId>
    <version>2.3.2</version>
    <scope>provided</scope>
</dependency>

To get these in the classpath, I have to use the Oracle dependency:

<dependency>
    <groupId>com.sun.faces</groupId>
    <artifactId>jsf-impl</artifactId>
    <version>2.2.20</version>
    <scope>provided</scope>
</dependency>

Obviously, we want to ditch using this package altogether at some point, but I was hoping there was a way to include this in our Jakarta migration.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
dentyne
  • 67
  • 1
  • 6

1 Answers1

5

The com.sun.faces.* is not part of Jakarta EE API. It's part of the Jakarta EE implementation. More precisely, it's the actual JSF implementation. Its name is "Mojarra".

You should indeed not need to have a dependency on it in your pom.xml in order to be JEE-implementation-independent (i.e. in order to be able to deploy your webapp to any JEE-compatible server without any code changes). If the code however doesn't compile when you remove it, then you apparently have somewhere a hard dependency on it, e.g. a hardcoded import or superclass referring to com.sun.faces.* package. This is indeed usually not correct.

The solution should be straight forward:

  1. Remove that Mojarra dependency
  2. Find all compilation errors
  3. Fix them one by one by using the standard JSF API approach
  4. If no one could be found, research or ask on Stack Overflow

See also:

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thank you! You say the "standard JSF API approach" - do you have any documentation links on that which I could share with our team? – dentyne Oct 05 '20 at 21:04
  • It just boils down to replacing `com.sun.faces.*` imports by `javax.faces.*` ones. If you can't find the standard API approaches/counterparts, then advance to point 4. It really depends on the specific use case. You didn't give any information about them, so it's hard to give a more specific answer suited for the specific use case. – BalusC Oct 05 '20 at 21:12
  • Oh sorry, I get that part. I meant I was looking for documentation on the fact that the best practice is to only include API Maven imports. – dentyne Oct 05 '20 at 22:23
  • It's just a general coding practice. See also https://stackoverflow.com/q/7295096 – BalusC Oct 06 '20 at 05:59