Q:

Erro ao atualizar o Java

Apareceu uma notificação padrão dizendo que havia uma nova atualização do Java disponível, então resolvi atualizar. Depois da atualização não consigo rodar meus aplicativos no Eclipse e aparece a seguinte mensagem:

Imports:
Classe 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;

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

Eu estava procurando nas bibliotecas no Java Build Path quando achei a biblioteca nativa do Android (Native library location) vazia e as anotações externas (External annotations). Seria isso um problema?
 
Bibliotecas

Mensagem de erro no log
Erro no log Eu tive que colocar no GitHub porque não coube aqui

A:

Em algum lugar do seu projeto CadastroDeProdutos deve haver isso:
import sun.misc.BASE64Encoder;

Por exemplo, vamos compilar essa classe abaixo:
import sun.misc.BASE64Encoder;
public class Teste {}

Ao fazer isso, o compilador do Java até a versão 8 imediatamente te dá uma warning:

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

Traduzindo:

BASE64Encoder é uma API interna proprietária e pode ser removida em uma versão futura

Esse aviso não deveria ser ignorado. As classes começando com sun. são internas da JDK e não deveriam NUNCA ser utilizadas diretamente. Por tal motivo, não há qualquer garantia quanto a estabilidade ou disponibilidade delas. Qualquer projeto que as utilize corre o risco de não ser portável.
Ou seja, na verdade o seu projeto esteve sempre errado desde o início devido ao fato dele utilizar uma classe que nunca deveria ter sido utilizada e compilava graças a uma falha na arquitetura da linguagem.
O aviso afirma que essa classe poderia ser removida em uma versão futura, e eis que um dia essa versão futura chegou! A partir do Java 9, os mecanismos adequados para esconder classes que não deveriam ser visíveis foram adicionados como parte do conceito de módulos. No entanto, a classe sun.misc.BASE64Encoder não foi apenas escondida. Ela foi de fato removida por completo de dentro da JDK.
No entanto, há uma solução simples para esse problema. A partir do Java 8, a classe java.util.Base64.Encoder foi adicionada. Logo, não há mais porque usar a sun.misc.BASE64Encoder. Entretanto, as APIs das duas classes têm algumas diferenças, embora não deva haver nada muito difícil de se migrar.
Pode até ser que você esteja usando uma biblioteca XPTO qualquer feita por terceiros e que essa biblioteca esteja usando o sun.misc.BASE64Encoder. Nesse caso a situação é um pouco mais complicada, porque aí é a biblioteca que está errada. Esse tipo de situação gerou algum rebuliço e muita gente achou ruim por causa dessas falhas inesperadas. Mas aí, voltamos ao que a warning relata, que essas classes não deveriam ser usadas diretamente, e portanto, o azar é de quem o fez ou confiou na biblioteca de alguém que fez isso.
Moral da história: Nunca use qualquer classe que comece com sun.. Não é a toa que elas tem um aviso bem grande dizendo que não devem ser utilizadas.

A:

Esta não é a resposta que eu gostaria de postar, mas vamos lá:
Primeiro, achei mais gente relatando esse bug ou no mínimo algo muito parecido:

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

Como eu disse na minha outra resposta, a classe sun.misc.BASE64Encoder foi removida do Java 9 e na verdade nunca deveria ter sido visível.
O Eclipse usa um plugin chamado ADT, desenvolvido pelo Google, para o desenvolvimento Android. Nas profundezas do código do ADT, a classe sun.misc.BASE64Encoder é utilizada por uma classe chamada SignedJarBuilder que está com um @Deprecated (fonte).
Entretanto, o desenvolvimento do ADT foi abandonado pelo Google em 2015 (1 e 2). A motivação foi porque o ADT está cheio de bugs e falhas de segurança e porque o Google quer forçar todo mundo a migrar para o Android Studio.
Assim sendo, as únicas soluções existentes são todas dolorosas:

Executar o Eclipse no Java 8. Tanto o Eclipse Oxygen quanto o Eclipse Photon necessitam do Java 8 no mínimo, então isso deve funcionar. Quando sair alguma futura versão do Eclipse que tenha como requisito mínimo, algum Java ≥ 9, isso não vai mais ser possível.
Migrar para o Android Studio. Ou talvez para o Netbeans ou alguma outra coisa.
Fazer um fork do ADT e corrigir esse e quaisquer outros bugs similares que venham a surgir. Provavelmente, isso é trabalhoso demais para valer a pena.

