MasterReplace, é um projeto swing sem nenhuma utilidade aparente. Sua única utilidade, ao menos para mim, é educativa, visando aprender e treinar além de um pouco de Orientação à Objetos, também a manipulação de arquivos.

Este programa altera letras, palavras ou textos em arquivos de texto, convertendo entre sí códigos de base HEXA, HTML ou ALPHA.
Um exemplo mais prático:

Supondo que eu possua um arquivo de 500 mil linhas, e em vários lugares deste arquivo existem letras acentuadas (á, ç, õ, etç), porém eu preciso destas letra em html (&Acute, &ccedil, etç), então eu seleciono um arquivo, escolho as opções “De Alpha” e “Para HTML”, e o programa se vira fazendo as alterações necessárias, sem perder nenhuma outra informação do arquivo.

Existe também a possibilidade de “traduzir” trechos de texto, em outra aba é possível digitar um texto qualquer, abaixo é possível selecionar “DE” e “PARA”, e na mesma caixa de texto o programa efetua a tradução.

Apesar desta  aparente “inutilidade”, o programa serve como exemplo para muitas outras coisas, principalmente para manipulação de arquivos, que será o foco dos próximos posts relacionados.

Downloads:

JAR (projeto executável – Java 6)
RAR (fontes do projeto – Java 6)

OBS.: Para executar o jar, digite no prompt de comando “java -jar ARQUIVO”, substituindo obviamente a palavra “ARQUIVO” pelo caminho e/ou nome do arquivo.

Aviso: Este post é quase um livro!

Algum tempo atraz, mas precisamente na matéria sobre WindowListener, comentei sobre a lógica necessária para enviar uma Janela Swing para a bandeja do sistema, ou Area de Notificação, ou SystemTray, ou como você gosta de chamar aquele cantinho inferior direito, ao lado do relógio, onde fica um aglomerado de ícones que as vezes nem conhecemos.

Teoricamente tudo é facil, o difícil é apenas implementar a solução ao nosso projeto já finalizado…
Mas vamos parar no pensamento que “tudo é facil”, e seguir em frente com este tutorial que ficou bem grande, e é quase todo código!

Primeiro vamos à lógica necessária:
Se você deseja enviar uma janela para a bandeja do sistema, desista, você nunca vai conseguir isso (ao menos em java), missão impossível.
O que podemos fazer é uma pequena “gambiarra”, invisível aos olhos de meros mortais.
Essa “POG” consiste em:

1º – Capturar o evento “MINIMIZAR” ou “FECHAR” ou qualquer outra porcaria que você queira.
2º – Deixar a janela que foi minimizada INVISÍVEL!
3º – Instanciar uma nova classe que coloca um icone bonitinho ao lado do relógio.
4º – Colocar um menu flutuante nesse icone (Menu Popup)
5º – Capturar os eventos de click nos itens deste menu
6º - Caso o item selecionado seja “Abrir novamente a jenela principal” deve-se deixar o frame principal VISIVEL novamente e “matar” as variáveis utilizadas para criar o icone bonitinho ao lado do relógio.

Viu que legal? Não se envia uma janela para o relógio, mas engana-se o usuário deixando a janela invisível e criando OUTRA janela sem corpo, apenas com um icone e um menu Popup!

Agora que já estamos com a faca e o queijo na mão, vamos ao que interessa!

Antes de mais nada, precisamos de uma janela, para que esta seja minimizada, então vamos criar uma classe chamada “Janelinha“, conforme exemplo:

package br.teste.area.notificacao;

import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.WindowConstants;

public class Janelinha extends javax.swing.JFrame {
 
 static AreaNotificacao an = null;
 static Janelinha j = null;

 public static void main(String[] args) {
      j = new Janelinha();
      j.setVisible(true); 
}
 
 public Janelinha() {
      super(“Oi, me minimiza…”);
      constroiJanelinha();
}
 
 private void constroiJanelinha() {
  try {
   setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
   setLocationRelativeTo(null);
   pack();
   setSize(200, 50);
  
   //Listener que capitura o evento “minimizar”
   addWindowListener(
     new WindowAdapter(){
      public void windowIconified(WindowEvent evnt){
       //Deixa a janela atual (Janelinha) invisível!
       setVisible(false);
       //Instancia a classe responsável pelo ícone na área de notificação.
       getAreaNotificacao();
      
      }
     }
   );
  
  } catch (Exception e) {
   e.printStackTrace();
  }
}

void getAreaNotificacao(){
  if(an == null){
   an = new AreaNotificacao();
  }
}

}

Esta é a classe principal que na verdade é nossa coadjuvante, só servirá para ser minimizada.
Repare no WindowListener, o que ele faz…
No WindowListener, estamos deixando o frame invisível “setVisible(false)”, na verdade ele continua vivinho da silva, a memória ocupada, o processamento em alta, execução de processos à todo vapor, porém não está visivel.
Após esta poção da invisibilidade, está sendo chamado o método interno “getAreaNotificacao()”, e sua única finalidade é instanciar a classe “AreaNotificacao”, e é nesta classe que a mágica vai acontecer!

IMPORTANTE: Repare também que as duas principais variáveis desta classe são static! Mas por que isso? A resposta na prática está logo abaixo, a resposta na teoria é simples, essas duas variáveis serão únicas em toda a aplicação, e precisam ser acessadas por outra janela (a classe AreaNotificacao), quando a classe AreaNotificacao for acessar estes objetos, precisamos ter certeza que eles são os mesmos objetos/variáveis/referências utilizados pela classe Janelinha, caso contrário a mágica não será tão boa.

Agora, vamos à classe secundária que na verdade é nossa protagonista.

package br.teste.area.notificacao;

import java.awt.AWTException;
import java.awt.Image;
import java.awt.MenuItem;
import java.awt.PopupMenu;
import java.awt.SystemTray;
import java.awt.TrayIcon;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.net.URL;

import javax.swing.ImageIcon;
import javax.swing.JFrame;
import javax.swing.JOptionPane;

public class AreaNotificacao {

 //Criação da icone, instancia da classe java java.awt.TrayIcon
 static TrayIcon trayIcon = null;
 
 //Referencia à instancia “J” da classe Janelinha, para acesso da bandeja.
 static Janelinha pai = Janelinha.j;
 
 //Construtor, que será chamado quando a classe for instanciada
AreaNotificacao() {
  super();
  criaAreaNotificacao();
}
 
 static void criaAreaNotificacao(){
 
  //Verifica se não é possível trabalhar com “TrayIcon”
  if (!SystemTray.isSupported()) {
            System.out.println(“Não dá pra fazer, nem tenta!”);
            return;
        }
 
  //Instanciação de um objeto java.awt.PopupMenu
  final PopupMenu pop = new PopupMenu();
  //Instanciação do objeto java.awt.SystemTray;
  final SystemTray tray = SystemTray.getSystemTray();
  //Criação do objeto TrayIcon, informando uma imagem e um título
  trayIcon = new TrayIcon(createImage(“padraoTray.jpg”, “É nois!!”));
 
  //Criação dos itens do Menu Popup
  MenuItem item_1 = new MenuItem(“111111″);
  MenuItem item_2 = new MenuItem(“222222″);
  MenuItem item_3 = new MenuItem(“333333″);
  MenuItem item_4 = new MenuItem(“444444″);
  MenuItem item_5 = new MenuItem(“-sair-”);
 
  //Adicionando os itens ao Menu Popup
  pop.add(item_1);
  pop.add(item_2);
  //Separador (linha que separa os itens no menu)
  pop.addSeparator();
  pop.add(item_3);
  pop.add(item_4);
  //Separador (linha que separa os itens no menu)
  pop.addSeparator();
  pop.add(item_5);
 
  //Setando o menu padrão no TrayIcon, que por acaso é este logo acima.
  trayIcon.setPopupMenu(pop);
 
  //Adicionando o Icone na Area de Notificação, como o menu já está dentro do ícone,
  //irá junto também.
  try {
            tray.add(trayIcon);
        } catch (AWTException e) {
            System.out.println(“Não deu pra fazer isso…”);
            return;
        }

//Ação do botão “item_1″
  item_1.addActionListener(new ActionListener(){
    public void actionPerformed(ActionEvent e) {
     //Simplesmente deixa-se a janela visível novamente.
     pai.setVisible(true);
     //Esta linha deixa a janela sobre as outras, caso ela apareça minimizada.
     pai.setExtendedState(JFrame.NORMAL);

try {
    //Agora basta remover (ou esconder) o ícone da Área de Notificação
     tray.remove(trayIcon);
     trayIcon = null;
     //Limpando a referência ao Systemtray da classe Janelinha
     pai.an.finalize();
    } catch (Throwable e1) {
     e1.printStackTrace();
    }
    }
  });
 
  //Ação do botão “item_2″
  item_2.addActionListener(new ActionListener(){
    public void actionPerformed(ActionEvent e) {
     JOptionPane.showMessageDialog(null, “Você clicou no item 2″);
    }
  });
 
  //Ação do botão “item_3″
  item_3.addActionListener(new ActionListener(){
    public void actionPerformed(ActionEvent e) {
     JOptionPane.showMessageDialog(null, “Você clicou no item 3″);
    }
  });
 
  //Ação do botão “item_4″
  item_4.addActionListener(new ActionListener(){
    public void actionPerformed(ActionEvent e) {
     JOptionPane.showMessageDialog(null, “Você clicou no item 4″);
    }
  });
 
  //Ação do botão “item_5″
  item_5.addActionListener(new ActionListener(){
    public void actionPerformed(ActionEvent e) {
     JOptionPane.showMessageDialog(null, “Você clicou no item 5, este item é proibido, agora a aplicação terá que ser encerrada!!!”);
     JOptionPane.showMessageDialog(null, “Escondam-se todos!!!!!”);
     System.exit(0);
    }
  });

}

protected static Image createImage(String path, String description) {
        URL imageURL = AreaNotificacao.class.getResource(path);
      
        if (imageURL == null) {
            System.err.println(“Caminho não encontrado: “ + path);
            return null;
        } else {
            return (new ImageIcon(imageURL, description)).getImage();
        }
    }

}

Toda a explicação aparentemente necessária está nos comentários ca classe, porém vamos à algumas observações.
Antes de executar qualquer coisa, e ocupar espaço à toa na memória, é feita uma verificação na JVM “if(!SystemTray.isSupported())”, se ela não suportar trabalhar com a classe SystemTray, então a brincadeira acaba.

Após isso são criados o Menu Popup e seus Itens, que no final ficam com essa cara:

Com o Icone criado, e o Menu Popup Definido, é hora de colocar o bolo para assar, isso está sendo feito logo após a inclusão dos itens no menu, primeiro definindo o Menu Padrão do Icone “trayIcon.setPopupMenu(pop)”, e depois, dentro do bloclo TRY-CATCH o ícone está sendo inserido na Bandeja do Sistema “tray.add(trayIcon)”.

Está tudo funcionando, tudo muito bonito, mas os itens precisão de ações não é mesmo?
As ações que merecem um comentário em especial são as do item_1 e do item_5.

Na ação do item_1, que neste caso está exibindo a janela principal novamente, deve-se impreterivelmente remover e/ou limpar as variáveis responsáveis pelo Icone na Bandeja do Sistema, caso contrário em cada minimizada um novo ícone será criado e cedo ou tarde seu computador vai gritar pedindo socorro.
É possível notar também o acesso às variáveis/objetos estáticos (static) da classe Janelinha, definindo novos comportamentos para eles.

Na ação do item_5 é realizado um “salve-se quem puder”, mais conhecido como “System.exit(0)” que encerra a aplicação inteira, ou seja, tudo que estiver no mesmo espaço da JVM será encerrado, o ícone na bandeja e a propria “Janelinha”.

Acha que isso é tudo? Isso é só o começo!
Não poderia ser tão simples (a nível de conteúdo), queremos mais!

É possível entrar para o clube dos chatos e ficar exibindo aqueles balõezinhos que incomodam à todos.

Para fazer essa mensagem chata, basta em algum momento, chamar a seguinte linha:
trayIcon.displayMessage(“Titulo”, “Mensagem”, tipo);

Trocando “Título” e “Mensagem”, obviamente pelos títulos e mensagens que serão exibidos no balão, e tipo por um dos seguintes tipos de mensagens:

TrayIcon.MessageType.ERROR
TrayIcon.MessageType.WARNING
TrayIcon.MessageType.INFO
TrayIcon.MessageType.NONE

Exemplos:

trayIcon.displayMessage(
“Atenção”,
“Perigo de causar o fim do mundo!”,
TrayIcon.MessageType.WARNING);

trayIcon.displayMessage(
“Alerta Vermelho!”,
“Este é um alerta de que o mundo está acabando”,
TrayIcon.MessageType.ERROR);

Agora que a parte facil já está aprendida, ou ao menos subentendida, agora é hora de partir para a parte difícil, adaptar a solução à um programa finalizado, mas para ajudar um pouco mais segue o link das classes de exemplo, utilizadas neste tutorial. Basta colocá-las no mesmo pacote e executar a classe “Janelinha”.

Janelinha.java
AraNotificacao.java
padraoTray.jpg

Boa sorte!

Posted in Java Dicas, Swing Tagged: ActionEvent, actionListener, Area de Notificação, Bandeja do Sistema, MenuItem, PopupMenu, SystemTray, Tray, TrayIcon, WindowAdapter, WindowEvent, WindowListener ]]> http://codeerror.wordpress.com/2009/09/29/swing-icone-na-area-de-notificacao/feed/ 0 codeerror Imagem da classe AreaNotificacao em ação, com o menu Popup sendo acessado Imagem do balão de avisos. http://codeerror.wordpress.com/2009/09/06/webservice-simples-assim-parte-4/ http://codeerror.wordpress.com/2009/09/06/webservice-simples-assim-parte-4/#comments Sun, 06 Sep 2009 19:20:53 +0000 codeerror http://codeerror.wordpress.com/2009/09/06/webservice-simples-assim-parte-4/ ]]>

Realizando um teste básico

O Axis aceita que um Web Service seja chamado via uma requisição HTTP-GET. Portanto, ao digitar um endereço é possível testar o web service. No exemplo deste artigo o endereço é este: http://localhost:8080/axis/Servico.jws?method=soma&valor1=2&valor2=4 .

Como pode-se notar, o endereço é a junção de um namespace, que é o endereço do WebService representado por http://localhost:8080/axis/Servico.jws , a variável method que, como seu nome diz, contém o nome do método que se deseja executar, e uma sequência dos parâmetros deste método. Lembrando que o nome dos parâmetros deve ser o mesmo definido na função da classe.

O resultado da execução é um documento XML com a resposta 6 . Novamente, dependendo do browser não será visivel as tags XML. O XML que retornou na execução está abaixo:

<?xml version=”1.0″ encoding=”UTF-8″?>
<soapenv:Envelope
      xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”
      xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
      xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<soapenv:Body>
<somaResponse soapenv:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<somaReturn xsi:type=”xsd:int”>6</somaReturn>
</somaResponse>
</soapenv:Body>
</soapenv:Envelope>

Criando um cliente em Java para acessar o Servidor

O cliente também é uma classe simples, mas exige conhecimento em algumas classes não tão comuns no dia-a-dia.

As classes Service e Call são classes do Axis , portanto, para compilar e executar esta classe é necessário que todo o diretório lib, encontrado dentro do zip do Axis esteja no CLASSPATH da aplicação.

Visto este detalhe, abaixo encontra-se o arquivo fonte do cliente de Web Service. Esta classe fará a conexão ao Web Service para somar 2 com 4 e irá apresentar o resultado 6 na saída padrão.

import org.apache.axis.client.Service;
import org.apache.axis.client.Call;
public class Cliente {
     public static void main(String[] args) throws Exception {
          // Endereço, local onde encontra-se o Web Service
          String local = “http://localhost:8080/axis/Servico.jws”;
         // Criando e configurando o serviço
          Call call = (Call) new Service().createCall();
         // Configurando o endereço.
          call.setTargetEndpointAddress(local);
          // Marcando o método a ser chamado.
          call.setOperationName(“soma”);
          // Parâmetros da função soma.
          Object[] param = new Object[]{new Integer(2),new Integer(4)};
         // Retorno da Função
          Integer ret = (Integer)call.invoke(param);
         // Imprime o resultado: ret = 2 + 4.
          System.out.println(“Resultado da soma : “ + ret);
     }
}

Este código está dentro de um arquivo chamado Cliente.java, após compilar e executar esta classe exibirá o resultado ” Resultado da soma: 6 “ como desejado.

O framework do Axis trata a primitiva int e a classe wrapper Integer como sendo iguais. Portanto, tanto faz usar uma ou outra. Neste exemplo, foi criado o Web Service com dois parâmetros int e aqui no cliente estamos usando dois parâmetros Integer .

Como pode-se notar, o framework do Axis abstrai qualquer trabalho com XML, evitando que o desenvolvedor necessite conhecer a sintaxe do XML do SOAP.

E com isso, chegamos ao fim deste tutorial, boa sorte no desenvolvimento do seu webservice!

Implementando um Web Service simples

O objetivo é aprender, então será criado um serviço bem simples. O serviço é a soma de duas variáveis inteiras retornando o resultado. Este exemplo poderá servir para qualquer outra implementação. Abaixo está a classe implementada. O nome do arquivo é Servico.java:

public class Servico {
      public int soma(int valor1, int valor2) {
            return valor1 + valor2;
      }
}

Agora só falta disponibilizá-lo no nosso servidor para o mundo acessar. E, para fazer isso, deve-se alterar o nome do arquivo de Servico.java para Servico.jws, coloca-lo no diretório: CATALINA_HOME / webapps / axis / e iniciar o servidor, se ele já não estiver iniciado. Se já estiver iniciado, o seu Web Service está publicado.

Os arquivos. jws são lidos pelo Axis e representam Java Web Services. O Axis se baseará nesses arquivos (. jws) para criar os arquivos de definição WSDL. Todos os métodos públicos existentes nessas classes serão automaticamente disponibilizados para terceiros.

Criar documentos XML é demorado e, muitas vezes, chato. Gerar o WSDL é uma característica muito relevante na escolha de uma implementação de SOAP e o Axis é um dos poucos frameworks que conseguem fazer essa façanha de maneira transparente para o desenvolvedor. É por esse motivo que ele é altamente recomendado na construção de Web Services.

Para acessar o Web Service criado basta abrir um navegador e ir ao endereço: http://localhost:8080/axis/Servico.jws . Da mesma forma que os outros dois Web Services foram vistos, este também terá um link para ver a especificação WSDL, e novamente poderá ser visto ou não dependendo do seu navegador.

O arquivo WSDL da classe Servico ficará como abaixo:

<?xml version=”1.0″ encoding=”UTF-8″?>
<wsdl:definitions targetNamespace=”http://localhost:8080/axis/Servico.jws”   
       xmlns=”http://schemas.xmlsoap.org/wsdl/”   
       xmlns:apachesoap=”http://xml.apache.org/xml-soap”   
       xmlns:impl=”http://localhost:8080/axis/Servico.jws”   
       xmlns:intf=”http://localhost:8080/axis/Servico.jws”   
       xmlns:soapenc=”http://schemas.xmlsoap.org/soap/encoding/”   
       xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”   
       xmlns:wsdlsoap=”http://schemas.xmlsoap.org/wsdl/soap/”   
       xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>  
    <wsdl:message name=”somaRequest”>  
<wsdl:part name=”valor1″ type=”xsd:int”/>  
<wsdl:part name=”valor2″ type=”xsd:int”/>  
   </wsdl:message>  
   <wsdl:message name=”somaResponse”>  
<wsdl:part name=”somaReturn” type=”xsd:int”/>  
   </wsdl:message>  
   <wsdl:portType name=”Servico”>  
     <wsdl:operation name=”soma” parameterOrder=”valor1 valor2″>  
<wsdl:input message=”impl:somaRequest” name=”somaRequest”/>  
       <wsdl:output message=”impl:somaResponse” name=”somaResponse”/>  
     </wsdl:operation>  
   </wsdl:portType>  
<wsdl:binding name=”ServicoSoapBinding” type=”impl:Servico”>  
<wsdlsoap:binding style=”rpc” transport=”http://schemas.xmlsoap.org/soap/http”/>  
     <wsdl:operation name=”soma”>  
       <wsdlsoap:operation soapAction=”"/>  
       <wsdl:input name=”somaRequest”>  
         <wsdlsoap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”   
             namespace=”http://DefaultNamespace” use=”encoded”/>  
       </wsdl:input>  
       <wsdl:output name=”somaResponse”>  
         <wsdlsoap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”   
             namespace=”http://localhost:8080/axis/Servico.jws” use=”encoded”/>  
       </wsdl:output>  
     </wsdl:operation>  
   </wsdl:binding>  
   <wsdl:service name=”ServicoService”>  
<wsdl:port binding=”impl:ServicoSoapBinding” name=”Servico”>  
<wsdlsoap:address location=”http://localhost:8080/axis/Servico.jws”/>  
     </wsdl:port>  
   </wsdl:service>  
</wsdl:definitions>  

Analisar este arquivo é essencial para entender a profundidade da implementação. Uma das linhas mais importantes para este arquivo é a 19ª linha, onde define-se o nome do método e o nome de seus parâmetros. Eles deverão ser de conhecimento público para que as interfaces cliente consigam se comunicar com o Web Service.

O que são Controladores ou Modificadores de Acesso?
Com certeza você já os viu, aqui mesmo neste blog. O projeto JSF, jReMSN, Hibernate e até mesmo o projeto Webservice estão cheios deles, mas o que são?

• default
• public
• private
• protected
• final
• abstract

Como pode ver, essas são palavras que sempre nos acompanham nas declarações de classes, métodos e variáveis, aqui vamos ver uma breve descrição de cada uma.

Classes
Para criar classes, só podemos utilizar dois controladores de acesso, na verdade um controlador (default) e um modificador (public).
É possível adicional à declaração da classe, junto com o public ou default, alguns outros modificadores como final e abstract.
Esses e todos os outros modificadores são acessíveis também à métodos e variáveis.

default
O controlador de acesso default é, como o próprio nome diz, padrão, ele está presente em TODAS as classes que não possuam um modificador, ele não é uma palavra que você indica na declaração da classe, na verdade, para utilizá-lo você não deve dizer nada para a classe!
Vejamos um exemplo básico:

class MinhaClasse{
}

Viu? Essa classe acima está utilizando o controlador de acesso default, esse controlador está presente em todas as classes que não tem uma declaração implícita (public), e ele define que esta classe está acessível à todas as classes DO MESMO PACOTE. Se você tentar instanciar ou extender esta classe de qualquer outra classe do mesmo pacote irá conseguir, porém se tentar fazer isso com uma classe de outro pacote não conseguirá!

public
O modificador de acesso public é exatamente isso, um modificador de acesso, quando declaramos uma classe como public estamos modificando o acesso, permitindo que todas as classes do projeto, indiferente do pacote consigam enxergar esta classe.
Exemplo:

public class MinhaClasse{
}

Esta classe acima conseguirá ser instanciada ou extendida por qualquer outra classe, indiferente do pacote que a instanciadora esteja!

final
O modificador final indica que está classe/método/variável termina aqui, esta é a ultima instancia, deste ponto em diante não muda mais!
Quando utilizado em classes, o final não deixa esta classe ser extendida (herdada), ela pode apenas ser instanciada. Desta forma você garante que os métodos desta classe serão utilizados sempre da mesma forma e nunca serão sobreescritos.

abstract
Abstract funciona de forma contrária ao final, uma classe abstract pode ser herdada, porém nunca poderá ser instanciada, funcionando apenas como “matéria prima” para a criação de uma nova subclasse que à extender.
A classe abstract pode possuir métodos abstracts, e estes não precisam possuir conteúdo, apenas a “assinatura”, quando um método for marcado como abstract, ele deverá obrigatóriamente ser reescrito na subclasse e ai sim irá possuir um conteúdo.
Exemplo:

abstract class MinhaClasse{
       public abstract String meuMetodo();
}

Repare que o método não possui conteúdo, nem ao menos possui chaves “{}”, e termina com ponto-e-vírgula! Que absurdo!
Mas não é nenhum absurdo, esse código irá compilar sem problema algum e está 100% correto, isso por que esta é uma classe abstract e o método também é um método abstract, ou seja a classe só pode ser extendida, e a classe que fizer isso será obrigada a possuir um método com o nome meuMetodo() e retorno String.
Uma classe abstract pode também possuir métodos e variáveis normais, que também serão herdados para as subclasses.

private
Quando você declara um método ou variável como private, você o está escondendo do resto do mundo, nenhuma outra classe do seu projeto conseguirá enxergar os métodos e variáveis private, eles só serão acessíveis dentro da própria classe!

protected
Este é o primo de segundo  grau do acesso default, quando declaramos um método ou variável com acesso protected estamos informando que para instancias, este método ou variável só está acessível à classes do mesmo pacote (idêntico ao acesso default), porém note que eu destaquei o trecho “para instancias” e isso tem um motivo, a diferença do protected para o default é em casos de herança, se a classe que possui o tal método protected for extendida por outra classe, mesmo que de pacote diferente, o método protected estará acessível à esta subclasse.