Eclipse Maven Web项目中org.glassfish.jersey.internal.util缺失Base64类求助

Hey there! Let's unpack why that Base64 class vanished and what you should do instead.

The Core Reason: Internal API Deprecation & Removal #

First off, any class in a package named internal (like org.glassfish.jersey.internal.util) is part of Jersey's private, internal implementation—it was never meant for public use. These internal APIs come with no backward compatibility guarantees, so Jersey's development team reserves the right to modify or remove them at any time.

Starting with specific versions of Jersey 2.x, the team removed this internal Base64 implementation entirely. The main driver here is that Java 8 and later already includes a robust, standard java.util.Base64 class that covers all Base64 encoding/decoding needs. There’s simply no need for Jersey to maintain its own internal version when a reliable, built-in alternative exists.

Recommended Alternatives #

Since relying on internal APIs is never a good practice (as you’ve just experienced), here are your best options:

• Use the JDK's built-in java.util.Base64 (most preferred):
  This requires zero extra dependencies and is part of standard Java. Example usage:

  // Encoding
  String encoded = Base64.getEncoder().encodeToString("your-string".getBytes(StandardCharsets.UTF_8));
  
  // Decoding
  byte[] decodedBytes = Base64.getDecoder().decode(encoded);
  String decoded = new String(decodedBytes, StandardCharsets.UTF_8);
  

• Apache Commons Codec's org.apache.commons.codec.binary.Base64:
  If your project already uses Apache Commons, this is a stable alternative. Add the dependency to your pom.xml if you haven’t already:

  <dependency>
      <groupId>commons-codec</groupId>
      <artifactId>commons-codec</artifactId>
      <version>1.15</version> <!-- Use the latest stable version -->
  </dependency>
  

• Skip hunting for another Jersey internal class:
  Don’t waste time looking for another hidden Jersey class to replace this one—stick to public, supported APIs instead to avoid future breakage.

Key Takeaway #

Always steer clear of libraries' internal packages/classes. They’re not designed for external use, and their removal or modification can break your code unexpectedly. Stick to standard JDK features or well-maintained third-party libraries for long-term stability.

内容的提问来源于stack exchange，提问作者SUNIL CHITYALA