Error while updating Java

Question

A standard notification came up saying that there was a new Java update available, so I decided to update. After the update I can’t run my apps on Eclipse and the following message appears:

Imports:

Class Cadastrar

import android.app.Activity;
import android.content.Intent;
import android.graphics.Bitmap;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.ImageView;
import android.widget.Toast;

Main Class

import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.TextView;

I was searching the libraries in the Java Build Path when I found the native Android library (Native library Location) empty and the external annotations (External Annotations). Would that be a problem?

Libraries

Error message in log Log error I had to put it on Github because it didn’t fit here

Answer 1

Somewhere in your project CadastroDeProdutos there must be this:

import sun.misc.BASE64Encoder;

For example, let’s compile this class below:

import sun.misc.BASE64Encoder;
public class Teste {}

By doing this, the Java compiler up to version 8 immediately gives you a Warning:

Teste.java:1: warning: BASE64Encoder is internal proprietary API and may be removed in a future release
import sun.misc.BASE64Encoder;
               ^

Translating:

Base64encoder is a proprietary internal API and can be removed in a future version

This warning should not be ignored. Classes starting with sun. are internal to the JDK and should not NEVER be used directly. Therefore, there is no guarantee as to their stability or availability. Any project that uses them runs the risk of not being portable.

That is, in fact his project was always wrong from the beginning due to the fact that he used a class that should never have been used and compiled thanks to a flaw in the architecture of the language.

The warning states that this class could be removed in a future version, and behold, one day this future version has arrived! Starting with Java 9, the appropriate mechanisms to hide classes that should not be visible were added as part of the module concept. However, the class sun.misc.BASE64Encoder not only was it hidden. It was in fact completely removed from inside the JDK.

However, there is a simple solution to this problem. From Java 8, the class java.util.Base64.Encoder added. So, there’s no more use for sun.misc.BASE64Encoder. However, the Apis of the two classes have some differences, although there shouldn’t be anything too difficult to migrate.

It may even be that you are using any third-party XPTO library and that this library is using the sun.misc.BASE64Encoder. In that case the situation is a little more complicated, because that is the wrong library. This kind of situation generated some commotion and many people found it bad because of these unexpected failures. But then, we return to what the Warning reports, that these classes should not be used directly, and therefore, bad luck is of those who made it or trusted the library of someone who did it.

Moral of the story: Never use any class that starts with sun.. No wonder they have a big warning that they should not be used.

Answer 2

This is not the answer I’d like to post, but come on:

First, I found more people reporting this bug or at least something very similar:

• https://stackoverflow.com/q/47216694/540552

• http://www.androidiani.com/forum/iniziare-programmare-android/542624-problema-sun-misc-base64encoder.html

• https://www.concretepage.com/questions/585

Like I said in my other answer, the class sun.misc.BASE64Encoder was removed from Java 9 and should never actually have been visible.

Eclipse uses a plugin called ADT, developed by Google, for Android development. In the depths of ADT code, the class sun.misc.BASE64Encoder is used by a class called SignedJarBuilder who is with a @Deprecated (source).

However, the development of ADT was abandoned by Google in 2015 (1 and 2). The motivation was because ADT is full of bugs and security holes and because Google wants to force everyone to migrate to Android Studio.

Therefore, the only existing solutions are all painful:

• Run Eclipse in Java 8. Both Eclipse Oxygen and Eclipse Photon need Java 8 at least, so this should work. When any future version of Eclipse comes out with a minimum requirement, some Java 9, this will no longer be possible.

• Migrate to Android Studio. Or maybe to Netbeans or something else.

• Make an ADT log and fix this and any other similar bugs that come up. Probably, this is too much work to be worth it.