IBM SDK and Runtime Environment for Linux Platforms, Java 2 Technology Edition, Version 5.0
Autor: Diogenes Buarque | Publicado: 2009-08-21T08:16:00-07:00

Guia do Usuário  Informações de Direitos Autorais Nota: Antes de utilizar estas informações e o produto que elas suportam, certifique-se de ler as informações gerais em Avisos. Esta edição do Guia do Usuário aplica-se aos seguintes sistemas: IBM 32-bit SDK and Runtime Environment for Linux on Intel architecture, Java 2 Technology Edition, Version 5.0IBM 64-bit SDK and Runtime Environment for Linux on AMD64/EM64T architecture, Java 2 Technology Edition, Version 5.0IBM 32-bit SDK and Runtime Environment for Linux on iSeries and pSeries, Java 2 Technology Edition, Version 5.0IBM 64-bit SDK and Runtime Environment for Linux on iSeries and pSeries, Java 2 Technology Edition, Version 5.0IBM 31-bit SDK and Runtime Environment for Linux on zSeries, Java 2 Technology Edition, Version 5.0IBM 64-bit SDK and Runtime Environment for Linux on zSeries, Java 2 Technology Edition, Version 5.0 e para todos os releases e modificações subseqüentes, até que seja indicado de outra maneira em novas edições. (c) Direitos Autorais Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Todos os direitos reservados. (c) Direitos Autorais International Business Machines Corporation, 1999, 2005. Todos os direitos reservados. Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corporation.  Prefácio Este Guia do Usuário oferece informações gerais sobre o IBM(R) SDK and Runtime Environment for Linux(TM) Platforms, Java(TM) 2 Technology Edition, Version 5.0 e informações específicas sobre as diferenças da implementação da IBM comparadas com a implementação da Sun. Leia este Guia do Usuário juntamente com a documentação mais extensa encontrada no Web site da Sun: http://java.sun.com. Para obter a lista de distribuições com as quais o SDK e o Runtime Environment para Linux foram testados, consulte: http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html. O Manual de Diagnóstico fornece informações mais detalhadas sobre o IBM Virtual Machine para Java. Os termos "Runtime Environment" e "Java Virtual Machine" são utilizados alternadamente neste Guia do Usuário. As alterações técnicas feitas neste Guia do Usuário para a Versão 5.0, com exceção de alterações menores ou óbvias, como a atualização de "1.4.2" para "5.0", estão indicadas em vermelho ao visualizar em HTML ou em uma cópia impressa colorida e por barras verticais à esquerda das alterações.   Índice Informações de Direitos Autorais Prefácio Visão Geral Convenções Compatibilidade entre Versões Fazendo Upgrade do SDK Migrando de Outros IBM JVMs| |Hardware Suportado  para zSeries Conteúdo do SDK e Runtime Environment Ferramentas do Runtime Environment Ferramentas do SDK Instalando e Configurando o SDK e o Runtime Environment Instalando no RHEL (Red Hat Enterprise Linux) 4| |Instalando um SDK de 32 bits em uma Arquitetura de 64 bits Instalando a partir de um Arquivo RPM Instalando a partir de um Arquivo .tgz Configurando o SDK e o Runtime Environment para Linux Definindo o PATH Definindo o CLASSPATH Desinstalando o SDK e o Runtime Environment para Linux Desinstalando o Pacote RPM (Red Hat Package Manager) Instalável Desinstalando o Pacote TAR (Tape Archive) Compactado Utilizando o Runtime Environment Opções Especificando Opções Java e Propriedades de Sistema Opções Padrão Opções Não Padrão Obtendo o Número de Construção e Versão IBM Globalização do Comando Java O Compilador JIT (Just-In-Time) Desativando o JIT Ativando o JIT Determinando se o JIT Está Ativado Especificando a Política de Coleta de Lixo Opções de Coleta de Lixo Tempo de Pausa Redução do Tempo de Pausa Ambiente com Heaps Muito Cheios Como a JVM Processa Sinais Sinais Utilizados pela JVM  Vinculando um Driver de Código Nativo à Biblioteca de Cadeia de Sinais Trabalhando com Pilhas Flutuantes Transformando Documentos XML Utilizando uma Versão Mais Antiga do Xerces ou Xalan Utilizando o SDK para Desenvolver os Aplicativos Java Depurando os Aplicativos Java JDB (Java Debugger) Determinando se o Aplicativo Está Sendo Executado em uma JVM de 32 ou 64 bits  Escrevendo Aplicativos JNI| |Suporte para Recuperação de Nível de Encadeamento de Conectores Bloqueados Trabalhando com Applets Executando Applets com o Applet Viewer Depurando Applets com o Applet Viewer| |Configurando a Alocação da Memória de Página Grande Suporte ao CORBA Suporte para GIOP 1.2 Suporte para Interceptadores Portáteis Suporte para Serviço de Nomes Interoperável Propriedades do Sistema para Rastrear o ORB Propriedades do Sistema para Ajustar o ORB Permissões de Segurança do Java 2 para o ORB Classes de Implementação do ORB RMI sobre IIOP Implementando o Conjunto da Rotina de Tratamento de Conexão para RMI Suporte ao BiDirectional Avançado BigDecimal Avançado Suporte ao Símbolo Euro Utilizando o Java Communications API (JavaComm) Instalando o Java Communications API Local dos Arquivos do Java Communications API Configurando o Java Communications API Alterando o Modo de Acesso das Portas Seriais e Paralelas Ativando Portas Seriais no IBM ThinkPads Limitação ao Imprimir com o Java Communications API Desinstalando o Java Communications API Desinstalando o Pacote RPM (Red Hat Package Manager) Instalável Desinstalando o Pacote TAR (Tape Archive) Compactado Documentação do Java Communications API Implementando os Aplicativos Java (Linux IA de 32 bits e PPC32 apenas) Utilizando o Plug-in Java Navegadores Suportados Instalando e Configurando o Plug-in Java Suporte a DOM (Document Object Model) Utilizando Parâmetros DBCS Utilizando Web Start (Somente Linux IA 32 bits, PPC32 e PPC64) Executando o Web Start Remessa dos Aplicativos Java| |Compartilhamento de Dados de Classe Entre JVMs| |Visão Geral sobre o Compartilhamento de Classe| |Conteúdo do Cache| |Atualização Dinâmica do Cache| |Ativando o Compartilhamento de Classe| |Segurança do Cache| |Tempo de Vida do Cache| |Utilitários do Cache| |Utilizando as Opções da Linha de Comandos para Compartilhamento de Classe| |Criando, Preenchendo, Monitorando e Excluindo um Cache| |Desempenho e Consumo de Memória| |Limitações e Considerações sobre Como Utilizar o Compartilhamento de Classe| |Limites no Tamanho do Cache| |Modificação do Bytecode de Tempo de Execução| |Limitações do Sistema Operacional| |Utilizando SharedClassPermissions| |Adaptando Carregadores de Classe Personalizados às Classes de Compartilhamento Serviço e Suporte para Fornecedores Independentes de Software Acessibilidade Acessibilidade iKeyman Keyboard Traversal dos Componentes JComboBox no Swing Acessibilidade do Web Start (Somente Linux IA 32-bit, PPC32 e PPC64)  Limitações Conhecidas Limitações que se Aplicam a Todas as Plataformas Linux, Exceto Onde Indicado Limitações do Linux IA 32-bit Limitações do Linux AMD64 Limitações do Linux PPC 32-bit e 64-bit Limitações do Linux PPC 64-bit Limitações do Linux zSeries 64-bit Limitações do Linux zSeries de 31 bits e de 64 bits Algum Comentário Sobre este Guia do Usuário? Avisos Marcas Registradas   Visão Geral O IBM SDK é um ambiente de desenvolvimento para gravação e execução de applets e aplicativos compatíveis com o IBM Java 5.0 Core Application Program Interface (API).  O SDK inclui o Runtime Environment para Linux, que permite somente a execução de aplicativos Java. Se você instalou o SDK, o Runtime Environment está incluído. O Runtime Environment contém o Java Virtual Machine e os arquivos de suporte, incluindo arquivos de classe e arquivos .so não depuráveis. O Runtime Environment contém apenas um subconjunto das classes localizadas no SDK e permite suportar um program Java no tempo de execução, mas não permite compilar programas Java. O Runtime Environment para Linux não inclui nenhuma das ferramentas de desenvolvimento, como appletviewer, o compilador Java (javac) ou as classes que pertençam apenas aos sistemas de desenvolvimento. Além das plataformas para IA32, PPC32 e AMD64/EM64T,o pacote Java Communications API (Application Programming Interface) é fornecido para utilização com o Runtime Environment para Linux. Informações sobre ele podem ser encontradas em Utilizando o Java Communications API (JavaComm).  O arquivo license_xx.html contém o contrato de licença para o software Runtime Environment para Linux. (xx é a abreviação do idioma.)Para exibir ou imprimir o contrato de licença, abra o arquivo em um navegador da Web.   Convenções Em todo este Guia do Usuário o diretório de instalação padrão do SDK se refere ao /opt/ibm/java2-i386-50/. As plataformas listadas a seguir apresentam diferentes diretórios de instalação padrão; substitua o diretório para a plataforma que está sendo utilizada quando você visualizar /opt/ibm/java2-i386-50/: Linux IA 32-bit: /opt/ibm/java2-i386-50/Linux AMD 64-bit: /opt/ibm/java2-x86_64-50/Linux PPC 32-bit: /opt/ibm/java2-ppc-50/Linux PPC 64-bit: /opt/ibm/java2-ppc64-50/Linux zSeries 31-bit: /opt/ibm/java2-s390-50/Linux zSeries 64-bit: /opt/ibm/java2-s390x-50/  Compatibilidade entre Versões Em geral, qualquer applet ou aplicativo que seja executado com uma versão anterior do SDK deverá ser executado corretamente com o IBM SDK for Linux, v5.0. Não há garantia de que as classes compiladas com esta versão funcionem com as versões anteriores. Para ler a documentação da Sun sobre compatibilidade, consulte o Web site da Sun em http://java.sun.com.  Fazendo Upgrade do SDK Se você estiver fazendo upgrade do SDK de um release anterior, faça backup de todos os arquivos de configuração e arquivos de política de segurança antes de continuar com o upgrade. Depois do upgrade, pode ser necessário restaurar ou reconfigurar esses arquivos porque o processo de upgrade pode tê-los excluídos. Verifique a sintaxe dos novos arquivos antes de restaurar os arquivos originais porque o formato ou opções de tais arquivos podem ter sido alteradas.   Migrando de Outros IBM JVMs Na Versão 1.4.2 para AMD64/EM64T, e Versão 5 para as outras plataformas Linux, o IBM Runtime Environment para Linux contém novas versões do IBM Java Virtual Machine e do compilador JIT (Just-In-Time). Se você estiver migrando de um IBM Runtime Environment mais antigo, observe que:  A JVM biblioteca compartilhada libjvm.so é instalada no diretório jre/bin/j9vm. Isso é diferente, por exemplo, no Runtime Environment for Linux para Version 1.4.2 (para todas as plataformas que não sejam AMD64/EM64T), onde está instalado em jre/bin/classic. Os aplicativos nativos que utilizam a interface de chamada JNI podem precisar incluir o novo caminho de diretório em sua variável ou variáveis de ambiente para localizar a biblioteca de link dinâmico JVM.|A JVMMI (JVM Monitoring Interface) não está mais disponível. |Você deve reescrever os aplicativos que utilizem essa API. Em vez disso, recomenda-se |a utilização da JVMTI (JVM Tool Interface). A JVMTI não é funcionalmente o |equivalente da JVMMI. Para obter informações sobre a JVMTI, consulte http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/ e o Manual de Diagnóstico.|A nova implementação do JNI está em conformidade com a especificação do JNI, |porém é diferente da implementação antiga. Ela retorna cópias de objetos em vez |de atribuir os objetos. Essa diferença pode expor erros no código do aplicativo |JNI. Para obter informações sobre a depuração do código JNI, consulte -Xcheck:jni em Opções Não Padrão.|O formato e o conteúdo dos logs detalhados do coletor de lixo obtidos |utilizando -verbose:gc foram alterados. Os dados agora são formatados |como XML. O conteúdo dos dados reflete as alterações na implementação da coleta de lixo |na JVM, e a maioria das estatísticas produzidas foi alterada. |Você deve alterar quaisquer programas que processem o resultado do GC detalhado para que |funcionem com o novo formato e os novos dados. Consulte o Manual de Diagnóstico para obter um exemplo dos novos dados do GC detalhado.Versões anteriores do IBM JRE enviadas com um arquivo chamado rt.jar no diretório jre/lib. No Java v1.4 e versões posteriores, esse arquivo foi substituído por vários arquivos JAR que residem no diretório jre/lib.|Para obter informações adicionais sobre compatibilidade de segmento de |mercado e APIs obsoletas, consulte Sun's |Java 5 Compatibility Documentation  e |Sun's Java 5 Depreciated API List | | |Hardware Suportado  para zSeries |Os SDKs e Runtime Environments de 31 e 64 bits |do zSeries executam nos |seguintes servidores System z9 e zSeries ou equivalentes:  ||z9-109|z990|z900|z890|z800  Conteúdo do SDK e Runtime Environment O SDK contém várias ferramentas de desenvolvimento e um JRE (Java Runtime Environment). Esta seção descreve o conteúdo das ferramentas do SDK e o Runtime Environment. Os aplicativos escritos totalmente em Java não devem ter dependências na estrutura de diretório do IBM SDK (ou arquivos desses diretórios).  Qualquer dependência na estrutura de diretório do SDK (ou os arquivos desses diretórios) poderiam resultar em problemas de portabilidade do aplicativo.   Ferramentas do Runtime Environment Classes Críticas -- Esses são os arquivos das classes compartilhadas para a plataforma e devem permanecer compactados para que o compilador e o interpretador os acessem. Não modifique essas classes; em vez disso, crie subclasses e substitua onde for necessário.Ferramentas JRE -- As ferramentas a seguir são parte do Runtime Environment e estão no diretório jre/bin, a menos que especificado de outra forma.   java (Intepretador Java)  Executa classes Java. O Interpretador Java executa programas que são escritos na linguagem de programação Java.javaw (Interpretador Java) Executa as classes Java da mesma forma que o comando java, porém não utiliza uma janela do console.keytool (Ferramenta de Gerenciamento de Chaves e Certificados) Gerencia um armazenamento (banco de dados) de chaves privadas e suas cadeias de certificados X.509 associadas que autenticam as chaves públicas correspondentes. policytool (Ferramenta de Criação e Gerenciamento de Arquivos de Políticas) Cria e modifica os arquivos de configuração de política externa que definem a política de segurança Java da instalação.rmid (daemon do sistema de ativação do RMI) Inicia o daemon do sistema de ativação para que esses objetos possam ser registrados e ativados em uma JVM (Java Virtual Machine).tnameserv (Serviço de Nomes do CORBA (Common Object Request Broker Architecture)) Inicia o serviço de nomes do transiente CORBA.rmiregistry (Registro do Objeto Remoto Java) Cria e inicia um registro de objeto remoto na porta especificada do host atual.ikeyman (utilitário GUI do iKeyman) Permite gerenciar chaves, certificados e pedidos de certificado. Para obter mais informações, consulte o Security Guide acompanhante e http://www.ibm.com/developerworks/java/jdk/security. O SDK também fornece uma versão da linha de comandos desse utilitário. Consulte Acessibilidade iKeyman para obter detalhes. jextract (Extrator de dump) Converte um dump produzido pelo sistema em um formato comum que pode ser utilizado pelo jdmpview. Para obter mais informações, consulte Manual de Diagnóstico.(Somente Linux IA 32-bit, PPC32 e PPC64) javaws (Java Web Start) Ativa a implementação e a manutenção automática dos aplicativos Java.(Somente Linux IA 32-bit, PPC32 e PPC64) |updateSettings.sh (configurações do Java Web Start) Configura o sistema para utilizar o Web Start com o navegador. Para obter informações adicionais, consulte Executando o Web Start. Este arquivo está instalado no diretório jre/lib/javaws.   Ferramentas do SDK As seguintes ferramentas fazem parte do SDK e estão localizadas no diretório /opt/ibm/java2-i386-50/bin : javac (Compilador Java) Compila programas que são escritos na linguagem de programação Java em bytecodes (código Java compilado).appletviewer (Java Applet Viewer) Testa e executa applets fora de um navegador da Web.jdb (Depurador Java) Ajuda a depurar os programas Java.javap (Class File Disassembler) Desmonta os arquivos compilados e pode imprimir uma representação dos bytecodes.javadoc (Java Documentation Generator) Gera páginas HTML da documentação de API nos arquivos de origem Java.javah (Gerador de Cabeçalho C e Arquivo Stub) Permite associar métodos nativos ao código escrito na linguagem de programação Java.jar (Java Archive Tool) Combina vários arquivos em um único arquivo JAR (Java Archive).jarsigner (Ferramenta de Assinatura e Verificação JAR) Gera assinaturas para arquivos JAR e verifica as assinaturas dos arquivos JAR assinados.jconsole (JConsole Monitoring and Management Tool - experimental) Ferramenta gráfica compatível com JMX (não suportada) experimental para monitoramento de JVMs locais e remotas. native2ascii (Conversor de Nativo para ASCII) Converte um arquivo de codificação nativa em um arquivo ASCII que contenha caracteres codificados em Latino 1 ou Unicode ou ambos.rmic (Conversor Stub do Java RMI (Remote Method Invocation)) Gera stubs, estruturas e conexões para objetos remotos. Inclui o suporte RMI sobre Internet Inter-ORB Protocol (RMI-IIOP).java-rmi.cgi (ferramenta de redirecionamento de pedido HTTP a CGI) Aceita pedidos RMI via HTTP e os redireciona para um servidor RMI atendendo em qualquer porta. idlj (IDL para Compilador Java) Gera ligações Java de um determinado arquivo IDL.serialver (Comando da Versão Serial) Retorna o serialVersionUID para uma ou mais classes em um formato adequado para copiar em uma classe envolvida. extcheck (Utilitário Extcheck) Detecta os conflitos da versão entre um arquivo jar de destino e os arquivos jar de extensão instalados atualmente. jdmpview (Formatador dump entre plataformas) Uma ferramenta que permite analizar dumps. Para obter mais informações, consulte Manual de Diagnóstico.(Somente Linux IA 32-bit, PPC32 e PPC64) htmlconverter (Conversor HTML do Java Plug-in) Converte uma página HTML que contenha applets em um formato que possa utilizar o Java Plug-in.ARQUIVOS DE INCLUSÃO Cabeçalhos C para programas JNI.DEMOS  O diretório demo contém vários subdiretórios que contêm código fonte de amostra, demos, aplicativos e applets, que você pode utilizar. DIREITOS AUTORAIS Aviso de direitos autorais para o software SDK for Linux.LICENÇA O arquivo LICENSE, /opt/ibm/java2-i386-50/docs//license_.html, contém o contrato de licença do software SDK para Linux (em que  é o nome do código de idioma, por exemplo,  En_US). Para exibir ou imprimir o contrato de licença, abra o arquivo em um navegador da Web. FIXES.LST Um arquivo de texto que descreve todos os defeitos que forem corrigidos após a liberação inicial desta versão.  Nota: os Guias do Usuário e Javadoc, e as  licenças, arquivos de direitos autorais e diretório demo acompanhantes, são a única documentação incluída nesse SDK para Linux. No Web site da Sun, é possível tanto visualizar quanto fazer download do pacote de documentação de software da Sun: http://java.sun.com.  Instalando e Configurando o SDK e o Runtime Environment Você pode instalar o IBM Java SDK e o Runtime Environment a partir de um arquivo RPM ou .tgz. A menos que deseje permitir que os usuários na máquina acessem esta instalação Java, utilize o método de instalação .tgz.  Se você não tiver acesso raiz, utilize o arquivo .tgz. Se você instalar utilizando um arquivo RPM, os arquivos Java serão instalados em /opt/ibm/java2-i386-50/. Os exemplos neste guia assumem que você tenha instalado o Java nesse diretório.  Instalando no RHEL (Red Hat Enterprise Linux) 4 O SDK depende de bibliotecas compartilhadas que, por padrão, não são instaladas para o RHEL (Red Hat Enterprise Linux) 4.0. Os RPMs que contêm essas bibliotecas são: compat-libstdc++-33-3.2.3 e xorg-x11-deprecated-libs-6.8.1 (Arquitetura Intel, PPC, e PPC64)compat-libstdc++-295-2.95.3 e xorg-x11-deprecated-libs-6.8.1 (zSeries) Para incluir essas bibliotecas durante a instalação do RHEL 4: Quando você chegar à tela Padrões do Pacote, selecione Customizar o Conjunto de Pacotes a Serem Instalados.Na tela Seleção de Grupo de Pacotes, sob Sistema X Windows, escolha Detalhes e certifique-se de que você tenha selecionado xorg-x11-deprecated-libs.Sob as opções de Desenvolvimento, selecione Desenvolvimento de Software Legado.| | |Instalando um SDK de 32 bits em uma Arquitetura de 64 bits |Para executar o SDK, é necessário instalar as versões corretas de todas as bibliotecas necessárias ao SDK: de 32 ou de 64 bits. |No RHEL4, as versões de 64 bits dos pacotes estão disponíveis no grupo de pacotes Suporte à Compatibilidade de Arquitetura. |Você pode utilizar a ferramenta RPM para verificar quais versões dos pacotes você instalou, incluindo a opção --queryformat "%{NAME}.%{ARCH}\n" no comando RPM. Exemplo: |/home/username : rpm --queryformat "%{NAME}.%{ARCH}\n" -q libstdc++|libstdc++.x86_64|libstdc++.i386  Instalando a partir de um Arquivo RPM Abra um prompt de shell e certifique-se de que seja root.Em um prompt de shell, digite rpm -ivh . Exemplo: |rpm -ivh ibm-java2--sdk-5.0-0.0..rpmou |rpm -ivh ibm-java2--jre-5.0-0.0..rpm |Em que  representa a arquitetura: |i386, x86_64, ppc, ppc64, s390 ou s390x.  Instalando a partir de um Arquivo .tgz Crie um diretório para armazenar os arquivos do pacote Java. Os exemplos neste guia assumem que você tenha instalado em /opt/ibm/java2-i386-50/. No restante do guia, substitua /opt/ibm/java2-i386-50/ pelo diretório no qual você instalou o Java.Em um prompt de shell, digite tar -zxvf arquivo<.tgz>. Exemplo: |tar -zxvf ibm-java2-sdk-50-linux-.tgzou |tar -zxvf ibm-java2-jre-50-linux-.tgz |Em que  representa a arquitetura: i386, x86_64, ppc, |ppc64, s390 ou s390x.  Configurando o SDK e o Runtime Environment para Linux  Definindo o PATH Observe que, se você alterar a variável de ambiente PATH como descrito a seguir, substituirá quaisquer arquivos executáveis Java existentes em seu caminho.  Depois de instalar o SDK, você poderá executar uma ferramenta digitando seu nome em um aviso de shell com um nome de arquivo como um argumento. É possível especificar o caminho para uma ferramenta digitando a cada vez o caminho antes do nome da ferramenta. Por exemplo, se o SDK para Linux estiver instalado em /opt/ibm/java2-i386-50/bin, você poderá compilar um arquivo denominado myfile.java, digitando o seguinte em um prompt de shell:   /opt/ibm/java2-i386-50/bin/javac myfile.java Para alterar a variável de ambiente PATH: Edite o arquivo de inicialização shell em seu diretório home (normalmente .bashrc, dependendo de seu shell) e inclua os caminhos absolutos na variável de ambiente PATH; por exemplo:  export PATH=/opt/ibm/java2-i386-50/bin:/opt/ibm/java2-i386-50/jre/bin:$PATHEfetue logon novamente ou execute o script shell atualizado para ativar a nova definição de PATH.  Definindo o CLASSPATH O CLASSPATH informa as ferramentas do SDK, como java, javac e javadoc, onde localizar as bibliotecas da classe Java. Será necessário definir o CLASSPATH explicitamente somente se uma das seguintes opções se aplicar: Você requer uma biblioteca ou arquivo de classe diferente, como aquela que você desenvolveu, mas ela não está no diretório atual.Você altera o local dos diretórios bin e lib de forma que eles não tenham mais o mesmo diretório pai comum.Você pretende desenvolver ou executar aplicativos que estão utilizando ambientes de tempo de execução diferentes no mesmo sistema. Para exibir o valor atual do CLASSPATH, digite o seguinte em um prompt de shell:   echo $CLASSPATH Se pretende desenvolver e executar aplicativos que utilizem ambientes de tempo de execução diferentes, incluindo outras versões que você tenha instalado separadamente, deverá definir o CLASSPATH (e o PATH) explicitamente para cada aplicativo. Se você pretende executar vários aplicativos simultaneamente e utilizar ambientes de tempo de execução diferentes, cada aplicativo deverá ser executado em sua própria shell. Se você pretende executar apenas uma versão do Java por vez, poderá utilizar um script shell para alternar entre os ambientes de tempo de execução diferentes.  Nota: (Apenas para usuários chineses do Linux IA de 32 bits) Em razão das inconsistências nas codificações de fontes no Red Hat Advanced Server, ao instalar em um ambiente no qual você deseja que o idioma padrão seja o chinês, é melhor instalar com o idioma padrão sendo o inglês e depois alterar para chinês, após a conclusão da instalação. Caso contrário, as fontes em chinês podem não ser exibidas.  Desinstalando o SDK e o Runtime Environment para Linux O processo utilizado para remover o SDK e o Runtime Environment para Linux depende do tipo de instalação que você utilizou. Veja instruções nos tópicos Desinstalando o Pacote RPM (Red Hat Package Manager) Instalável ou Desinstalando o Pacote TAR (Tape Archive) Compactado.  Desinstalando o Pacote RPM (Red Hat Package Manager) Instalável Para desinstalar o SDK ou o Runtime Environment para Linux, se você tiver instalado o pacote RPM instalável: Em um prompt de shell, Para verificar quais pacotes RPM você instalou, digite: rpm -qa | grep -i javaVocê verá uma lista de quaisquer pacotes IBM Java instalados; por exemplo: ibm-java2--jre-5.0-0.0.ibm-java2--sdk-5.0-0.0.Esta saída indica quais pacotes você pode desinstalar, utilizando o comando rpm -e; por exemplo: rpm -e ibm-java2--jre-5.0-0.0.rpm -e ibm-java2--sdk-5.0-0.0. Como alternativa, você pode utilizar uma ferramenta gráfica como kpackage ou yast2.Remova de sua instrução PATH o diretório no qual o SDK e o Runtime Environment foram instalados.Apenas ((Linux IA de 32-bit e somente PPC32) Se você instalou o Plug-in Java, remova os arquivos do Plug-in Java do diretório do navegador da Web.  Desinstalando o Pacote TAR (Tape Archive) Compactado Para desinstalar o SDK ou o Runtime Environment para Linux, se você tiver extraído o pacote TAR compactado: Remova os arquivos do SDK ou do Runtime Environment do diretório no qual o SDK ou Runtime Environment foi instalado.Remova de sua instrução PATH o diretório no qual você instalou o SDK ou Runtime Environment.Efetue logon novamente ou execute o script shell atualizado para ativar a nova definição de PATH.Apenas (Linux IA de 32 bits e AMD64/EM64T) Se você instalou o Plug-in Java, remova os arquivos do Plug-in Java do diretório do navegador da Web.  Utilizando o Runtime Environment A ferramenta java ativa um aplicativo Java iniciando um Java Runtime Environment e carregando uma classe especificada.  A JVM procura a classe inicial (e outras classes utilizadas) em três conjuntos de locais: no caminho de classe de auto-inicialização, nas extensões instaladas e no caminho de classe do usuário. Os argumentos especificados após o nome da classe ou o nome do arquivo JAR são passados para a função principal. O comando javaw é idêntico ao java, exceto que o javaw não possui janela de console associada. Utilize javaw quando não desejar que uma janela de prompt de comandos seja exibida. O ativador javaw exibirá uma caixa de diálogo com informações sobre erros se houver falha na ativação.  Os comandos java e javaw utilizam a seguinte sintaxe:  java [ opções ] class [ argumentos ... ]java [ opções ] -jar file.jar [ argumentos ... ]javaw [ opções ] class [ argumentos ... ]javaw [ opções ] -jar file.jar [ argumentos ... ]Os itens entre colchetes são opcionais.  opçõesOpções de linha de comandos. classNome da classe a ser chamada. file.jarNome do arquivo jar a ser chamado. Ele é utilizado apenas com -jar. argumentosArgumentos passados para a função main.  Se a opção -jar for especificada, o arquivo JAR nomeado irá conter arquivos de classe e recurso para os aplicativos com a classe de inicialização indicada pelo cabeçalho do manifesto Main-Class.   Opções O ativador possui um conjunto de opções padrão suportadas no ambiente de tempo de execução atual e que serão suportadas em releases futuros. Além disso, há um conjunto de opções fora do padrão. As opções padrão foram escolhidas para o melhor uso geral. Uma ação deve ser tomada se decidir fazer alterações.  Especificando Opções Java e Propriedades de Sistema Você pode especificar as opções do Java e as propriedades do sistema de 3 diferentes modos. São, por ordem de preferência: Especificar a opção ou propriedade na linha de comando, por exemplo java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass.Criar um arquivo que contenha as opções e especificá-lo na linha de comando com -Xoptionsfile= .Criar uma variável de ambiente denominada IBM_JAVA_OPTIONS  contendo as opções, por exemplo, exportIBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump".  As opções mais à direita na linha de comandos têm preferência em relação às mais a esquerda; por exemplo, se especificar as opções -Xint -Xjit myClass, -Xjit tem a preferência.   Opções Padrão  -D<property_name>=<valor> Define uma propriedade do sistema.-assert Imprime ajuda para opções relacionadas à declaração.-cp ou -classpath <diretórios e arquivos zip ou jar separados por :> Define o caminho da procura por classes e recursos de aplicativos. Se as opções -classpath  e -cp não forem utilizadas e CLASSPATH não estiver definido, o usuário classpath será, por padrão, o diretório atual (.).-help ou -? Exibe uma mensagem de utilização.-showversion Imprime a versão do produto e continua.-verbose:[class,gcterse,gc,dynload,stackwalk,sizes,stack,debug,jni] Ativa a saída verbosa.-version Exibe a versão do produto.-version: Requer a versão especificada para ser executado. -jre-restrict-search Inclui JREs privados do usuário na procura de versão-no-jre-restrict-search Exclui JREs privados do usuário da procura de versão-agentlib:<libname>[=<options>] carrega a biblioteca de agentes nativos , por exemplo  -agentlib:hprof.  Para obter mais informações, especifique -agentlib:jdwp=help  e -agentlib:hprof=help na linha de comandos.-agentpath:libname[=<options>] Carregar biblioteca de agentes nativos por nome de caminho completo-javaagent:<jarpath>[=<options>] Carregar agente da linguagem de programação Java; para obter mais informações; consulte a documentação da API java.lang.instrument. -X Imprime a ajuda sobre opções não padrão.  Opções Não Padrão As opções -X listadas a seguir não são opções padrão e, portanto, estão sujeitas a alterações sem aviso prévio.  Para opções que utilizam o parâmetro , você deve sufixar o número com "k" ou "K" para indicar kilobytes, "m" ou "M" para indicar megabytes ou "g" ou "G" para indicar gigabytes. -Xargencoding Permite colocar seqüências de escape Unicode na lista de argumentos. Por padrão, essa opção é definida como desligada.-Xbootclasspath:<diretórios e arquivos zip ou jar separados por ;> Define o caminho da procura por classes e recursos de auto-inicialização. O padrão é procurar classes e recursos de auto-inicialização dentro dos diretórios internos da VM e dos arquivos .jar.-Xbootclasspath/a:<diretórios e arquivos zip ou jar separados por ;> Anexa os diretórios, arquivos zip ou arquivos jar especificados ao final do caminho de classe de auto-inicialização. O padrão é procurar classes e recursos de auto-inicialização dentro dos diretórios internos da VM e dos arquivos .jar.-Xbootclasspath/p:<diretórios e arquivos zip ou jar separados por ;> Anexa os diretórios, arquivos zip ou arquivos jar especificados ao começo do caminho de classe de auto-inicialização. Não implemente aplicativos que utilizem a opção -Xbootclasspath: ou -Xbootclasspath/p: para substituir uma classe na API padrão, pois tal implementação violaria a licença do código binário do Java 2 Runtime Environment. O padrão é procurar classes e recursos de auto-inicialização dentro dos diretórios internos da VM e dos arquivos .jar. -Xcheck:jni Executa verificações adicionais das funções JNI. Também é possível utilizar -Xrunjnichk. Por padrão, nenhuma verificação é executada. -Xcheck:nabounds Executa verificações adicionais das operações de array JNI. Também é possível utilizar -Xrunjnichk. Por padrão, nenhuma verificação é executada. |-Xclassgc  ||Essa opção ativa a coleta de objetos de classe em cada coleta de lixo. |Essa opção está, por padrão, ativada. -Xcompactexplicitgc Compacta todas as chamadas para System.gc(). Consulte também -Xnocompactexplicitgc. Por padrão, a compactação ocorre somente quando acionada internamente.  -Xcompactgc Compacta todos os ciclos do Coletor de Lixo. Consulte também -Xnocompactgc. Por padrão, a compactação ocorre somente quando acionada internamente. |-Xconcurrentbackground  ||Essa opção especifica o número de encadeamentos de segundo plano de baixa prioridade conectados |para ajudar os encadeamentos mutadores na marcação simultânea. O padrão é 1. |-Xconcurrentlevel  ||Essa opção especifica a taxa de alocação "tax".  Ela indica a proporção |entre a quantidade de heap alocado e a quantidade de heap marcado. O padrão é 8.|-Xconmeter:  ||Essa opção determina qual uso da área, LOA ou SOA, é medido e, |portanto, quais alocações são taxadas durante a marcação simultânea. A utilização de -Xconmeter:soa aplica-se à taxa de alocação de SOA (Área de |Objeto Pequena); a utilização de -Xconmeter:loa aplica-se à |taxa de alocação de LOA (Área de Objeto Grande). Se -Xconmeter:dynamic 	for especificado, o coletor determinará dinamicamente |qual área será medida, com base em qual área é esgotada primeiro, se é |a SOA ou a LOA. A opção está configurada, por padrão, como -Xconmeter:soa. -Xdbg:<opções> Carrega bibliotecas de depuração para suporte da depuração remota de aplicativos. Equivale a -Xrunjdwp. Por padrão, as bibliotecas de depuração não são carregadas e a instância VM não é ativada para depuração.-Xdbginfo:<caminho para arquivo de símbolos> Carrega e transmite opções para o servidor de informações de depuração. Por padrão, o servidor de informações de depuração é desativado. -Xdebug Inicia a JVM com o depurador ativado. Por padrão, o depurador é desativado.|-Xdisableexcessivegc  ||Essa opção desativa a emissão de uma exceção OutOfMemory se for gasto |tempo excessivo no GC. Por padrão, essa opção é desativada.-Xdisableexplicitgc Informa a VM que as chamadas para System.gc() não devem ter nenhum efeito. Por padrão, as chamadas para System.gc() acionam uma coleta de lixo.|-Xdisablestringconstantgc  ||Essa opção impede que as cadeias existentes na tabela interna de cadeias sejam coletadas. |Essa opção está, por padrão, desativada.-Xdisablejavadump Desliga a geração de javadump em erros e sinais. Por padrão, a geração de javadump é ativada.|-Xenableexcessivegc  ||Se for gasto um tempo excessivo no GC, essa opção retornará NULL para um |pedido de alocação e fará com que uma exceção OutOfMemory seja emitida. Essa ação |ocorre somente quando o heap tiver sido totalmente expandido e o tempo gasto |estiver completando no mínimo 95%. Esse comportamento é o padrão.|-Xenablestringconstantgc  ||Essa opção ativa as cadeias da tabela interna de cadeias a serem coletadas. |Essa opção está, por padrão, ativada.-Xfuture Ativa verificações completas em formatos de arquivos de classe. Utilize esse sinalizador ao desenvolver um novo código, pois verificações mais completas serão o padrão em releases futuros. Por padrão, as verificações completas de formato são desativadas. -Xgcpolicy:[optthruput]|[optavgpause]|[gencon]||[subpool] (subconjunto no PPC e zSeries) Controla o comportamento do Coletor de Lixo. A opção optthruput é a padrão e proporciona um rendimento do processamento muito alto aos aplicativos, embora isso implique a ocorrência de pausas ocasionais. A opção optavgpause reduz o tempo gasto nessas pausas para coleta de lixo e limita o efeito do aumento do tamanho de heap durante a pausa para coleta de lixo. Utilize optavgpause se a sua configuração apresentar um heap muito grande. A opção gencon solicita o uso combinado de GC simultâneo e geracional para ajudar a minimizar o tempo gasto com qualquer pausa para coleta de lixo. |A opção subpool utiliza um algoritmo de alocação de objeto |aprimorado para obter melhor desempenho ao alocar objetos |no heap.  Essa opção pode melhorar o desempenho em grandes sistemas SMP. Para obter informações adicionais, consulte Especificando a Política de Coleta de Lixo.-Xgcthreads<número de encadeamentos> Define o número de encadeamentos auxiliares que são utilizados para operações paralelas durante a coleta de lixo. Por padrão, o número de encadeamentos é definido como o número de CPUs físicas presentes -1, com um mínimo de 1.|-Xgcworkpackets  ||Essa opção especifica o número total de pacotes de trabalho disponíveis no |coletor global. Se não for especificado, o coletor alocará um número de pacotes |com base no tamanho máximo de heap.-Xint Faz com que a JVM utilize apenas o Interpretador, desativando o compilador JIT (Just-In-Time). Por padrão, o compilador JIT é ativado.-Xiss Define o tamanho inicial da pilha de encadeamentos Java. Por padrão, 2 kilobytes. -Xjit[:<suboption>,<suboption>,...] Ativa o JIT. Para obter detalhes sobre as subopções, consulte o Manual de Diagnóstico. Consulte também -Xnojit. Por padrão, o JIT é ativado. -Xlinenumbers Exibe os números das linhas nos rastreios de pilha, para depuração. Consulte também -Xnolinenumbers. Por padrão, os números de linhas são ativados.  |-Xloa  ||Esta opção aloca uma LOA (Área de Objeto Grande). Os objetos serão |alocados nessa LOA em vez de no SOA. Por padrão, a LOA é ativada para todas as políticas |GC, exceto para subconjunto, em que a LOA não está disponível. Consulte |também -Xnoloa.|-Xloainitial  || entre 0 e 0,95, especifica a porcentagem inicial do espaço |permitido atual alocado para a LOA (Área de Objeto Grande). O padrão é 0,05 ou 5%. |-Xloamaximum  || entre 0 e 0,95, especifica a porcentagem máxima do espaço |permitido atual alocado para a LOA (Área de Objeto Grande). O padrão é 0,5 ou 50%. -Xlp Solicita à JVM para alocar o heap Java com páginas grandes. Se páginas grandes não estiverem disponíveis, a JVM não será iniciada, exibindo a mensagem de erro GC: a configuração do sistema não suporta a opção --> '-Xlp'. A JVM utiliza o shmget() para alocar as páginas grandes para o heap. As páginas grandes são suportadas pelos sistemas que executam o Linux kernels v2.6 ou superior, ou os kernels anteriores onde o suporte para páginas grandes foi retornado pela distribuição. Por padrão, as páginas grandes não são utilizadas. Consulte Configurando a Alocação da Memória de Página Grande.-Xmaxe<tamanho> Define o tamanho máximo de acordo com o qual o coletor de lixo expande o heap. Normalmente, o coletor de lixo expande o heap quando a quantidade de espaço livre cai abaixo de 30% (ou a quantidade especificada com  -Xminf), até atingir a quantidade necessária para restaurar o espaço livre para 30%. A opção -Xmaxe limita a expansão ao valor especificado; por exemplo, -Xmaxe10M limita a expansão a 10 MB. Por padrão, não há um tamanho máximo de expansão.-Xmaxf<tamanho> Especifica a porcentagem máxima de heap que deve estar livre após uma coleta de lixo. Se o espaço livre exceder esse valor, a JVM tentará reduzir o heap. Especifique o tamanho como um valor decimal no intervalo de 0 a 1. Por exemplo, -Xmaxf0.5 define o espaço livre máximo como 50%. O valor padrão é 0,6 (60%).-Xmca<tamanho> Define a etapa de expansão para a memória alocada para armazenar a parte RAM das classes carregadas. Toda vez que mais memória for necessária para armazenar classes na RAM, a memória alocada será aumentada de acordo com essa quantidade. Por padrão, a etapa de expansão é 32 K.-Xmco<tamanho> Define a etapa de expansão para a memória alocada para armazenar a parte ROM das classes carregadas. Toda vez que mais memória for necessária para armazenar classes na ROM, a memória alocada será aumentada de acordo com essa quantidade. Por padrão, a etapa de expansão é 128 K.-Xmine<tamanho> Define o tamanho mínimo de acordo com o qual o Coletor de Lixo expande o heap. Normalmente, o coletor de lixo expande o heap de acordo com a quantidade necessária para restaurar o espaço livre para 30% (ou a quantidade especificada com o uso de -Xminf). A opção -Xmine define a expansão de forma que ela corresponda no mínimo ao valor especificado; por exemplo, -Xmine50M define o tamanho da expansão como um mínimo de 50 MB. Por padrão, o tamanho mínimo de expansão é 1 MB.-Xminf<tamanho> Especifica a porcentagem mínima de heap que deve estar livre após uma coleta de lixo. Se o espaço livre estiver abaixo desse valor, a JVM tentará expandir o heap. Especifique o tamanho como um valor decimal no intervalo de 0 a 1; por exemplo, um valor de -Xminf0.3 solicita que o espaço livre mínimo corresponda a 30% do heap. Por padrão, o valor mínimo é 0,3.-Xmn<tamanho> Configura os tamanhos inicial e máximo do novo heap (nursery) para o valor especificado ao utilizar -Xgcpolicy:gencon. Equivale à definição de ambos -Xmns e -Xmnx.  |Se você definir -Xmns ou -Xmnx, não poderá definir -Xmn. Se você |tentar definir -Xmn com -Xmns ou -Xmnx, a VM não será iniciada e retornará um |erro. Por padrão, -Xmn é selecionado internamente de acordo com a capacidade do sistema. É possível utilizar a opção -verbose:sizes para encontrar os valores que a VM está utilizando atualmente. -Xmns<size> Configura o tamanho inicial do novo heap (nursery) para o valor especificado ao utilizar -Xgcpolicy:gencon. Por padrão, essa opção é selecionada internamente de acordo com a capacidade do sistema. |Essa opção retornará um erro se você tentar |utilizá-la com -Xmn.-Xmnx<size> Configura o tamanho máximo do novo heap (nursery) para o valor especificado ao utilizar -Xgcpolicy:gencon. Por padrão, essa opção é selecionada internamente de acordo com a capacidade do sistema. |Essa opção retornará um erro se você tentar |utilizá-la com -Xmn. -Xmo<tamanho> Configura os tamanhos inicial e máximo do heap antigo (tenured) para o valor especificado ao utilizar -Xgcpolicy:gencon. Equivale à definição de ambos -Xmos e -Xmox.  |Se você definir -Xmos ou -Xmox, não poderá definir -Xmo. Se você |tentar definir -Xmo com -Xmos ou -Xmox, a VM não será iniciada e retornará um |erro. Por padrão, -Xmo é selecionado internamente de acordo com a capacidade do sistema. É possível utilizar a opção -verbose:sizes para encontrar os valores que a VM está utilizando atualmente. -Xmos<size> Configura o tamanho inicial do heap antigo (tenure) para o valor especificado ao utilizar -Xgcpolicy:gencon. Por padrão, essa opção é selecionada internamente de acordo com a capacidade do sistema. |Essa opção retornará um erro se você tentar |utilizá-la com -Xmo.-Xmox<size> Configura o tamanho inicial do heap antigo (tenure) para o valor especificado ao utilizar -Xgcpolicy:gencon. Por padrão, essa opção é selecionada internamente de acordo com a capacidade do sistema. |Essa opção retornará um erro se você tentar |utilizá-la com -Xmo.-Xmoi<tamanho> Configura o valor de incremento do heap Java ao utilizar -Xgcpolicy:gencon. Se for definida como zero, nenhuma expansão será permitida. Por padrão, o tamanho do incremento é calculado sobre o tamanho da expansão, -Xmine e -Xminf.-Xmr<tamanho> Configura o tamanho do "conjunto memorizado" de Coleta de Lixo ao utilizar -Xgcpolicy:gencon. Essa é a lista de objetos no heap antigo (tenured) que possui referências aos objetos no novo (nursery) heap. Por padrão, essa opção é definida como 16 kilobytes. -Xms<tamanho> Define o tamanho de heap Java inicial.  É possível também utilizar -Xmo. O padrão é definir internamente de acordo com a capacidade do sistema. -Xmso<tamanho> Configura o tamanho da pilha C dos encadeamentos Java bifurcados. Por padrão, essa opção é definida como 32 kilobytes em plataformas de 32 bits e 256 kilobytes em plataformas de 64 bits.-Xmx<tamanho> Define o tamanho máximo do heap Java. Por padrão, essa opção é definida internamente de acordo com a capacidade do sistema. -Xnoclassgc Desativa coleta de lixo da classe. Isso desativa a coleta de lixo do armazenamento associado a classes Java que deixaram de ser utilizadas pela JVM. O comportamento padrão é -Xclassgc. -Xnocompactgc Desativa a compactação para o Coletor de Lixo. Consulte também -Xcompactgc. Por padrão, a compactação é ativada. -Xnocompactexplicitgc Desativa a compactação numa chamada para System.gc(). Consulte também -Xcompactexplicitgc. Por padrão, a compactação é ativada em chamadas para System.gc(). -Xnojit Desativa o compilador JIT. Consulte também -Xjit. Por padrão, o compilador JIT é ativado. -Xnolinenumbers Desativa os números de linhas para depuração. Consulte também -Xlinenumbers. Por padrão, os números de linhas são ativados.  |-Xnoloa  ||Esta opção impede a alocação de uma LOA (Área de Objeto Grande). Todos os |objetos serão alocados no SOA. Por padrão, a LOA é ativada para todas as políticas |GC, exceto para subconjunto, em que a LOA não está disponível. Consulte |também -Xloa.  -Xnopartialcompactgc Desativa a compactação incremental. Consulte também -Xpartialcompactgc. Por padrão, essa opção não é definida, portanto, todas as compactações são completas.  -Xnosigcatch Desativa o código de manipulação de sinal da JVM. Consulte também -Xsigcatch. Por padrão, a manipulação de sinal é ativada. -Xnosigchain Desativa o encadeamento da rotina de tratamento de sinal. Consulte também -Xsigchain. Por padrão, o encadeamento da rotina de tratamento de sinal é ativado.-Xoptionsfile=<file> Especifica um arquivo que contém opções e definições JVM. Por padrão, nenhum arquivo de opções é utilizado.-Xoss<tamanho> Configura o tamanho da pilha Java e da pilha C para qualquer encadeamento.  Essa opção é fornecida para compatibilidade e é equivalente a configurar tanto  -Xss quanto -Xmso para o valor especificado.  -Xpartialcompactgc Ativa a compactação parcial. Consulte também -Xnopartialcompactgc.-Xquickstart Melhora o tempo de inicialização atrasando a compilação JIT e as otimizações. Por padrão, o início rápido é desativado e não há retardo na compilação JIT.-Xrdbginfo:: Carrega e transmite opções para o servidor remoto de informações de depuração. Por padrão, o servidor remoto de informações de depuração é desativado. -Xrs Reduz o uso de sinais de sistema operacional. Por padrão, a VM utiliza totalmente os sinais do sistema operacional, consulte Sinais Utilizados pela JVM .-Xrun[:options] Carrega bibliotecas assistentes. Para carregar múltiplas bibliotecas, especifique-a mais de uma vez na linha de comandos. Exemplos dessas bibliotecas são: -Xrunhprof[:help] | [:<opção>=<valor>, ...] Executa o perfil do heap, da CPU ou do monitor. Para obter mais informações, consulte Manual de Diagnóstico. -Xrunjdwp[:help] | [:<opção>=<valor>, ...] Carrega bibliotecas de depuração para suporte da depuração remota de aplicativos. Equivale a -Xdbg. Para obter informações adicionais, consulte Depurando os Aplicativos Java.-Xrunjnichk[:help] | [:<option>=<value>, ...] Executa verificações adicionais nas funções do JNI para rastrear erros em programas nativos que acessam a JVM utilizando o JNI. Para obter mais informações, consulte Manual de Diagnóstico.|-Xscmx<size>[k|m|g] ||Para obter detalhes sobre o -Xscmx, consulte Utilizando as Opções da Linha de Comandos para Compartilhamento de Classe.|-Xshareclasses:<subopções> ||Para obter detalhes sobre as subopções -Xshareclasses, consulte Utilizando as Opções da Linha de Comandos para Compartilhamento de Classe. -Xsigcatch Ativa o código de manipulação de sinal da VM. Consulte também -Xnosigcatch. Por padrão, a manipulação de sinal é ativada -Xsigchain Ativa o encadeamento da rotina de tratamento de sinal. Consulte também -Xnosigchain. Por padrão, o encadeamento da rotina de tratamento de sinal é ativado.|-Xsoftrefthreshold<number>  ||Essa opção define o número de GCs após o qual uma referência do software será |limpa se seu referente não tiver sido marcado. O padrão é 3; isso significa que |no terceiro GC onde o referente não é marcado a referência do software será |limpa.-Xss<tamanho> Configura o tamanho de pilha Java máximo para qualquer encadeamento. Por padrão, essa opção está definida para 256 KB. Para obter mais informações, consulte  Trabalhando com Pilhas Flutuantes. -Xthr:<options> Define opções de encadeamento.-Xverbosegclog:<caminho para o arquivo><nome do arquivo>[X, Y] Faz com que a saída verboseGC seja gravada no arquivo especificado. Se o arquivo sair, ele será sobrescrito. Caso contrário, se um arquivo existente não puder ser aberto ou um novo arquivo não puder ser criado, a saída será redirecionada para stderr. Se você especificar os argumentos X e Y (ambos inteiros), a saída verboseGC será redirecionada ao número X de arquivos, cada um contendo o número Y de ciclos de coleta de lixo adequados para a saída verboseGC. Esses arquivos possuem o formato nome de arquivo1, nome de arquivo2 e assim por diante. Por padrão, nenhum log de coleta de lixo detalhado ocorre.-Xverify Ativa a verificação completa de classes para cada classe carregada. Por padrão, a verificação completa de classes é desativada. -Xverify:none Desativa a verificação completa de classes. Por padrão, a verificação completa de classes é desativada.   Obtendo o Número de Construção e Versão IBM Para obter o número de construção e versão IBM, em um prompt de comando shell, digite: java -version  Globalização do Comando Java O comando java e outros comandos do ativador java (por exemplo, javaw) permitem que um nome de classe seja especificado com qualquer caractere pertencente ao conjunto de caracteres do código de idioma atual.  Também é possível especificar qualquer caractere Unicode nos argumentos e no nome de classe utilizando seqüências de escape java. Para fazê-lo, será necessário especificar -Xargencoding. Para especificar um caractere Unicode, utilize seqüências de escape no formato \u####, em que # é um dígito hexadecimal (0 a 9, A a F). Como alternativa, para especificar que o nome de classe e os argumentos de comando possuem a codificação UTF8, utilize -Xargencoding:utf8 ou, na codificação ISO8859_1, utilize -Xargencoding:latin. Por exemplo, para especificar uma classe denominada "HelloWorld" utilizando a codificação Unicode para ambas as letras maiúsculas, utilize este comando: java -Xargencoding '\u0048ello\u0057orld' Os comandos java e javaw fornecem mensagens de saída traduzidas. Essas mensagens são diferentes com base no código do idioma em que o Java está sendo executado. As descrições detalhadas de erros e outras informações de depuração retornadas por java estão em inglês.  O Compilador JIT (Just-In-Time) O compilador IBM Just-In-Time (JIT) gera dinamicamente o código da máquina para seqüências de bytecodes utilizadas com freqüência em aplicativos e applets Java durante a execução. |O compilador JIT V5.0 |entrega novas otimizações como resultado da pesquisa do compilador, |melhora as otimizações implementadas em versões anteriores do JIT e fornece |exploração de hardware aprimorada.  O IBM SDK e o Runtime Environment incluem o JIT, que está ativado por padrão tanto nos aplicativos de usuário quanto nas ferramentas SDK.  Normalmente, não há nenhuma necessidade de chamar explicitamente o JIT; a compilação do bytecode Java para o código da máquina ocorre de modo transparente. Contudo, se encontrar um problema com o Runtime Environment durante a execução de um aplicativo ou applet Java, há a possibilidade de desativar o JIT para facilitar o isolamento do problema. A desativação do JIT deve ser um medida temporária apenas; ele é necessário para um desempenho adequado.   Desativando o JIT Há três maneiras de desativar o JIT: Configurar a variável de ambiente do JAVA_COMPILER para "NONE" ou esvaziar a cadeia antes da execução do aplicativo Java.  Digite o seguinte em um prompt de comandos:  Para o shell Korn:  export JAVA_COMPILER=NONE (Os comandos do shell Korn são utilizados para o restante deste Guia do Usuário.)Para o shell Bourne:  JAVA_COMPILER=NONE export JAVA_COMPILERPara o shell C:  setenv JAVA_COMPILER NONEUtilize a opção -D n linha de comandos da JVM para configurar a propriedade java.compiler para "NONE" ou para uma cadeia vazia:  java -Djava.compiler=NONE MyAppUtilize a opção -Xint na linha de comandos da JVM. Exemplo: java -Xint MyApp Ambas as opções da linha de comandos substituem a variável de ambiente JAVA_COMPILER.   Ativando o JIT Para ativar o JIT explicitamente, configure a variável de ambiente JAVA_COMPILER como "jitc" ou utilize a opção -D para configurar a propriedade java.compiler como "jitc". Como alternativa, utilize a opção -Xjit (e omita a opção -Xint) na linha de comandos da JVM para ativar o JIT.  Se a variável de ambiente JAVA_COMPILER ou a propriedade java.compiler estiver definida para "" (cadeia vazia), o JIT permanecerá desativado. Para remover a configuração da variável de ambiente apropriadamente,  digite unset JAVA_COMPILER no prompt do shell.    Determinando se o JIT Está Ativado Para determinar se o JIT está ativado, digite o seguinte no prompt de comandos:  java -version Se o JIT não estiver sendo utilizado, será exibida uma mensagem que inclui o seguinte:  (JIT disabled) Se o JIT estiver sendo utilizado, será exibida uma mensagem que inclui o seguinte:  (JIT ativado)  Para obter mais informações sobre o JIT, consulte o Manual de Diagnóstico.  Especificando a Política de Coleta de Lixo O Coletor de Lixo gerencia a memória utilizada pelo Java e pelos aplicativos em execução na VM. Quando o Coletor de Lixo recebe um pedido para armazenamento, a memória não utilizada no heap será colocada à parte -  "allocation".  O Coletor de Lixo também procura por áreas de memória que não são mais referenciadas e libera-as para reutilização - "collection". A fase de coleta pode ser acionada por um falha na alocação de memória, que ocorre quando não é deixado espaço para um pedido de armazenamento ou por uma chamada System.gc() explícita. A coleta de lixo pode afetar significativamente o desempenho do aplicativo; portanto, o IBM Virtual Machine oferece vários métodos de otimizar a forma com que a coleta de lixo é executada, reduzindo, dessa forma, o efeito no aplicativo. Para obter informações mais detalhadas sobre a coleta de lixo, consulte o Manual de Diagnóstico.  Opções de Coleta de Lixo A opção -Xgcpolicy especifica a política de coleta de lixo. -Xgcpolicy utiliza os valores optthruput (o padrão e o valor recomendado), optavgpause|, subpool| (somente PPC e |zSeries) ou gencon.  A opção controla o comportamento do coletor de lixo, fazendo trocas entre o throughput do aplicativo e o sistema geral, e faz com que os tempos de pausa sejam causados pela coleta de lixo. O formato da opção e seus valores são: -Xgcpolicy:optthruput -Xgcpolicy:optavgpause -Xgcpolicy:gencon |-Xgcpolicy:subpool (somente PPC e zSeries)  Tempo de Pausa Quando a tentativa de um aplicativo em criar um objeto não pode ser atendida imediatamente no espaço disponível no heap, o coletor de lixo é responsável pela identificação de objetos não referidos (lixo), por excluí-los e retornar o heap para um estado no qual pedidos de alocação imediatos e subseqüentes possam ser atendidos rapidamente. Tais ciclos de coleta de lixo introduzem pausas inesperadas ocasionais na execução do código do aplicativo. Como os aplicativos aumentam de tamanho e complexidade e os heaps tornam-se correspondentemente maiores, esse tempo de pausa da coleta de lixo tende a aumentar de tamanho e importância. O valor padrão da coleta de lixo, -Xgcpolicy:optthruput, fornece um rendimento alto para aplicativos, mas com o custo das pausas ocasionais, que podem variar de alguns milissegundos até vários segundos, dependendo do tamanho do heap e da quantidade de lixo.   Redução do Tempo de Pausa A JVM utiliza duas técnicas para reduzir tempos de pausa: Coleta de lixo simultâneaColeta de lixo com base em gerações A opção de linha de comandos -Xgcpolicy:optavgpause solicita o uso da coleta de lixo simultânea para reduzir significativamente o tempo gasto em pausas para coletas de lixo. A Coleta de Lixo Simultânea reduz o tempo de pausa executando algumas atividades de coleta de lixo simultaneamente à execução normal de programas para minimizar a interrupção causada pela coleta do heap. A opção -Xgcpolicy:optavgpause também limita o efeito do aumento do tamanho de heap durante a pausa para coleta de lixo. A opção -Xgcpolicy:optavgpause é mais útil para configurações que apresentam grandes heaps. Com o tempo de pausa reduzido, você poderá perceber uma certa redução no rendimento do processamento dos aplicativos. Durante a coleta de lixo simultânea, um tempo significativo é gasto com a identificação de objetos relativamente resistentes que não conseguem ser coletados. Se a Coleta de Lixo concentrar-se apenas nos objetos com a maior tendência de serem recicláveis, será possível reduzir ainda mais os tempos de pausa de alguns aplicativos. A Coleta de Lixo com Base em Gerações obtém o mesmo resultado dividindo o heap em duas "gerações", as áreas de "desenvolvimento" e "estabilidade". Os objetos são colocados em uma dessas áreas dependendo da duração. A área de desenvolvimento é a menor e contém objetos mais recentes, enquanto a área de estabilidade é maior e contém objetos mais antigos. Os objetos são alocados primeiro à área de desenvolvimento; se persistirem por um período suficiente, avançarão em algum momento para a área de estabilidade.  A Coleta de Lixo com Base em Gerações depende da curta duração da maioria dos objetos. Ela reduz os tempos de pausa concentrando-se na tentativa de reivindicar o armazenamento na área de desenvolvimento, pois essa área inclui a maioria do espaço reciclável. Em vez de tempos de pausa ocasionais, mas demorados, para coletar todo o heap, a área de desenvolvimento é coletada com mais freqüência e, se essa área for pequena o bastante, os tempos de pausa serão relativamente menores. Entretanto, a Coleta de Lixo com Base em Gerações apresenta a desvantagem da possibilidade de que, com o passar do tempo, a área de estabilidade fique lotada se vários objetos persistirem por muito tempo. Para minimizar o tempo de pausa quando essa situação ocorrer, utilize uma combinação da Coleta de Lixo Simultânea com a Coleta de Lixo com Base em Gerações. A opção -Xgcpolicy:gencon solicita o uso combinado dessas duas técnicas para ajudar a minimizar o tempo gasto com qualquer pausa para coleta de lixo.  Ambiente com Heaps Muito Cheios Se o heap Java estiver quase cheio, e houver pouco lixo para ser recuperado, os pedidos de novos objetos poderão não ser atendidos rapidamente por não haver espaço disponível de imediato. Se o heap for operado com capacidade quase cheia, o desempenho do aplicativo poderá ser afetado, independentemente de quais opções anteriores forem utilizadas; e, se os pedidos de mais espaço para o heap continuarem a ser feitos, o aplicativo receberá uma exceção OutofMemory, o que resultará na finalização da JVM caso a exceção não seja capturada e tratada. Nesse ponto, a JVM produz um arquivo de diagnósticos "javadump". Nessas condições, recomenda-se aumentar o tamanho do heap utilizando a opção -Xmx ou reduzir o número de objetos do aplicativo em uso. Para obter mais informações, consulte Manual de Diagnóstico.  Como a JVM Processa Sinais Quando surge um sinal que é do interesse da JVM, uma rotina de tratamento de sinais é chamada. Essa rotina de tratamento de sinais determina se o sinal foi chamado por causa de um encadeamento Java ou não-Java.  Se o sinal for por causa de um encadeamento Java, a JVM assumirá o controle do tratamento do sinal. Se uma rotina de tratamento de aplicativo para esse sinal for instalada e você não tiver especificado a opção de linha de comandos -Xnosigchain, após o término do processamento da JVM, essa rotina de tratamento será chamada.  Se o sinal for por causa de um encadeamento não-Java e o aplicativo que instalou a JVM tiver instalado anteriormente sua própria rotina de tratamento para o sinal, o controle será fornecido a essa rotina de tratamento. Caso contrário, se o sinal for solicitado pela JVM ou pelo aplicativo Java, ele será ignorado ou a ação padrão será executada.  Com relação aos sinais de exceção e erro, a JVM:  Trata a condição e se recupera, ouInsere uma seqüência de encerramento controlado em que ela:  Produz um Javadump, para descrever o estado da JVM em um ponto da falhaChama a rotina de tratamento de sinais do aplicativo em razão desse sinal.Chama todos os ganchos de interrupção instalados pelo aplicativo.Executa a limpeza necessária para fornecer um encerramento limpo. Para obter informações sobre como gravar um ativador que especifique os ganchos acima, consulte: http://www-106.ibm.com/developerworks/java/library/i-signalhandling/. Esse item foi gravado para o Java V1.3.1, mais ainda se aplica a versões mais recentes. Com relação aos sinais de interrupção, a JVM insere também uma seqüência de encerramento controlado, mas dessa vez ela é tratada como uma terminação normal:  Chama a rotina de tratamento de sinais do aplicativo em razão desse sinal.Executa todos os ganchos de encerramento do aplicativo.Chama todos os ganchos de saída instalados pelo aplicativo.Executa a limpeza necessária da JVM. O encerramento é idêntico ao encerramento iniciado por uma chamada para o método System.exit().  Outros sinais utilizados pela JVM destinam-se a propósitos de controle interno e não causam a sua terminação. O único sinal de controle de interesse é SIGQUIT, o que faz com que um Javadump seja gerado.   Sinais Utilizados pela JVM  A Tabela 1 a seguir mostra os sinais utilizados pela JVM. Os sinais são agrupados na tabela por tipo ou uso, como se segue: Exceções: O sistema operacional faz surgir sincronicamente um sinal de exceção apropriado sempre que uma condição fatal ocorre. Erro: a JVM fará surgir um SIGABRT caso detecte uma condição da qual ela não pode recuperar-se. Interrupções: Os sinais de interrupção surgem de maneira assíncrona, de fora de um processo JVM, para solicitar encerramento. Controles: Outros sinais são utilizados pela JVM para propósitos de controle.    Tabela 1. Sinais Utilizados pela JVM   Nome do Sinal Tipo de Sinal Descrição Desativado pelo -Xrs     SIGBUS Exceção Acesso incorreto à memória (alinhamento incorreto de dados) Sim   SIGSEGV Exceção Acesso incorreto à memória (gravar para memória inacessível) Sim   SIGILL Exceção Instrução inválida (tentativa de chamar uma instrução de máquina desconhecida) Não   SIGFPE Exceção Exceção de ponto flutuante (dividir por zero) Sim   SIGABRT Erro Finalização anormal. A JVM emite esse sinal sempre que detecta uma falha da JVM. Sim   SIGINT Interrupção Atenção interativa (CTRL-C). A JVM sai normalmente. Sim   SIGTERM Interrupção Pedido de finalização. A JVM sairá normalmente. Sim   SIGHUP Interrupção Interromper. A JVM sai normalmente. Sim   SIGQUIT Controle Um sinal de saída de um terminal. A JVM utiliza isso para conseguir Javadumps. Sim   |SIGTRAP (5) |Controle |Utilizada pelo JIT. |Sim   |__SIGRTMAX - 2 |Controle |Utilizada pelo SDK. |Não   |SIGCHLD |Controle |Utilizada pelo SDK para controle interno.  |Não    Utilize a opção -Xrs (reduz uso de sinais) para evitar que a JVM manipule a maior parte dos sinais. Para obter informações adicionais, consulte a página do ativador de aplicativos Java da Sun em http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html. Os sinais 1 (SIGHUP), 2 (SIGINT),  4 (SIGILL), 7 (SIGBUS), 8 (SIGFPE), 11 (SIGSEGV)  e 15 (SIGTERM) nos encadeamentos da JVM fazem com que a JVM seja encerrada. Portanto, uma rotina de tratamento de sinais de aplicativo não deve tentar uma recuperação a partir desses sinais, a menos que a JVM não seja mais necessária.   Vinculando um Driver de Código Nativo à Biblioteca de Cadeia de Sinais O Runtime Environment contém um recurso de encadeamento de sinais. A cadeia de sinais permite que a JVM interopere mais eficazmente com o código nativo que instala suas próprias rotinas de tratamento de sinais. O recurso de encadeamento de sinais permite que um aplicativo estabeleça um vínculo e carregue a biblioteca compartilhada libjsig.so antes das bibliotecas do sistema. A biblioteca libjsig.so assegura que as chamadas como signal(), sigset() e sigaction() sejam interceptadas para que suas rotinas de tratamento não substituam as rotinas de tratamento de sinais da JVM. Em vez disso, essas chamadas salvam as novas rotinas de tratamento de sinais ou as "encadeia" ocultas sob as rotinas de tratamento instaladas pela JVM. Mais tarde, quando qualquer um desses sinais surgir e for verificado que eles não se destinam à JVM, as rotinas de tratamento pré-instaladas serão chamadas. Para utilizar libjsig.so: Efetue o link com o aplicativo que cria ou incorpora uma JVM: gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.couUtilize a variável de ambiente LD_PRELOAD: export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash and ksh)setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)(Assumindo que JAVA_HOME esteja configurado; caso contrário, utilize /opt/ibm/java2-i386-50/jre.) Se você instalar rotinas de tratamento de sinais que utilizam sigaction(), alguns sa_flags não serão observados quando a JVM utilizar o sinal. São elas: SA_NOCLDSTOP - Isso nunca é definido. SA_NOCLDWAIT - Isso nunca é definido. SA_RESTART - Isso sempre é definido.A biblioteca libjsig.so também oculta do aplicativo rotinas de tratamento de sinais da JVM. Por essa razão, chamadas como signal(), sigset() e  sigaction() que são feitas após o início da JVM não retornam mais uma referência à rotina de tratamento de sinais da JVM; em vez disso, retornam qualquer rotina de tratamento que foi instalada antes da inicialização da JVM.  Trabalhando com Pilhas Flutuantes Distribuições específicas do Linux - Red Hat, por exemplo - possuem um recurso GLIBC ativado chamado 'pilhas flutuantes'. Por causa das limitações do kernel Linux, a JVM não será executada em hardware SMP com pilhas flutuantes ativadas caso o nível do kernel seja inferior a 2.4.10. Nesse ambiente, pilhas flutuantes devem ser desativadas antes que a JVM ou qualquer aplicativo que inicie a JVM seja iniciado. No Red Hat, utilize este comando para desativar pilhas flutuantes, exportando uma variável de ambiente:  export LD_ASSUME_KERNEL=2.2.5 Em um sistema Linux de pilha não-flutuante, independentemente do valor que for definido para -Xss, será fornecido um tamanho mínimo de pilha nativa de 256 KB para cada encadeamento. Em um sistema Linux de pilha flutuante, os valores -Xss são aceitos. Por isso, se você estiver migrando de um sistema Linux de pilha não-flutuante, será necessário assegurar-se de que todos os valores de -Xss sejam grandes o suficiente e que não dependam de um mínimo de 256 KB.   Transformando Documentos XML O IBM SDK contém o processador XSLT4J e o analisador XML4J que estão em conformidade com a especificação do JAXP 1.3. Essas ferramentas permitem que você analise e transforme documentos XML, independentemente de qualquer implementação de processamento XML específico. Ao utilizar "Factory Finders" para localizar as implementações SAXParserFactory,  DocumentBuilderFactory e TransformerFactory, seu aplicativo poderá alternar entre diferentes implementações sem precisar alterar qualquer código. |A tecnologia XML incluída com o IBM SDK é semelhante ao |Apache Xerces Java e Apache Xalan Java.  Consulte | http://xml.apache.org/xerces2-j/ e |http://xml.apache.org/xalan-j/  para obter |mais informações.  O processador XSLT4J permite que você escolha entre o processador Interpretativo XSLT original ou o novo processador de Compilação XSLT. O processador Interpretativo foi projetado para aprimorar e depurar ambientes. Ele suporta as funções de extensão XSLT não suportadas pelo processador de Compilação XSLT. O processador de Compilação XSLT foi projetado para ambientes de tempo de execução de alto desempenho; ele gera um mecanismo de transformação ou translet,  de uma folha de estilo XSL. Essa abordagem separa a interpretação das instruções da folha de estilo de seu aplicativo de tempo de execução para dados XML.   O processador Interpretativo XSLT é o processador padrão. Para selecionar o processador de Compilação XSLT você pode:  Alterar a entrada no arquivo jaxp.properties (localizado em /opt/ibm/java2-i386-50/jre/lib), ou Definir a propriedade do sistema da chave javax.xml.transform.TransformerFactory para org.apache.xalan.xsltc.trax.TransformerFactoryImpl.   Para implementar propriedades no arquivo jaxp.properties, copie jaxp.properties.sample para jaxp.properties em /opt/ibm/java2-i386-50/. Esse arquivo também contém detalhes completos sobre o procedimento utilizado para determinar as implementações que serão utilizadas para o TransformerFactory, o SAXParserFactory e o DocumentBuilderFactory. Para melhorar o desempenho ao transformar um objeto StreamSource com um processador de Compilação XSLT, especifique a classe com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager como o fornecedor do serviço org.apache.xalan.xsltc.dom.XSLTCDTMManager.  Para determinar o fornecedor de serviços, tente cada uma das etapas até localizar org.apache.xalan.xsltc.dom.XSLTCDTMManager: Verifique a configuração da propriedade de sistema org.apache.xalan.xsltc.dom.XSLTCDTMManager.Verifique o valor da propriedade org.apache.xalan.xsltc.dom.XSLTCDTMManager no arquivo /opt/ibm/java2-i386-50/lib/xalan.properties.Verifique o conteúdo do arquivo META-INF/services/org.apache.xalan.xsltc.dom.XSLTCDTMManager para um nome de classe.Utilize o fornecedor de serviços padrão, org.apache.xalan.xsltc.dom.XSLTCDTMManager.O processador de Compilação XSLT detecta o fornecedor de serviços para o serviço org.apache.xalan.xsltc.dom.XSLTCDTMManager quando um objeto javax.xml.transform.TransformerFactory é criado. Quaisquer objetos javax.xml.transform.Transformer ou javax.xml.transform.sax.TransformerHandler criados utilizando esse objeto TransformerFactory utilizarão o mesmo fornecedor de serviços. Os fornecedores de serviços só podem ser alterados modificando uma das configurações descritas acima e depois criando um novo objeto TransformerFactory.  Utilizando uma Versão Mais Antiga do Xerces ou Xalan Se você estiver utilizando uma versão mais antiga do Tomcat, essa limitação poderá existir. Se você estiver utilizando uma versão mais antiga do Xerces (anterior a 2.0) ou Xalan (anterior a 2.3) na substituição confirmada, poderá obter uma exceção de ponteiro nulo quando ativar o aplicativo. Essa exceção ocorre porque essas versões mais antigas não manipulam o arquivo jaxp.properties corretamente.  Para evitar essa situação, utilize uma das seguintes soluções alternativas: Faça upgrade para uma versão mais recente do aplicativo que implemente a especificação do Java API para XML Programming (JAXP) mais recente (http://java.sun.com/xml/jaxp/index.html).Remova o arquivo jaxp.properties de /opt/ibm/java2-i386-50/jre/lib.Remova o comentário das entradas do arquivo jaxp.properties em /opt/ibm/java2-i386-50/jre/lib.Defina explicitamente o SAX Parser, DocumentBuilder ou Transformer Factory utilizando a variável de ambiente IBM_JAVA_OPTIONS. Exemplo: export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl                      ou  export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl                     ou  export IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl  Defina a propriedade do sistema para javax.xml.parsers.SAXParserFactory , javax.xml.parsers.DocumentBuilderFactory ou javax.xml.transform.TransformerFactory a partir do seu código de aplicativo. Para obter um exemplo, consulte a especificação JAXP 1.3.  Utilizando o SDK para Desenvolver os Aplicativos Java As seções a seguir fornecem informações sobre como utilizar o SDK para Linux para desenvolver aplicativos Java. Consulte Ferramentas do SDK para obter detalhes sobre as ferramentas disponíveis.  Depurando os Aplicativos Java Para depurar os programas Java, utilize o aplicativo JDB (Java Debugger) ou outros depuradores que comunicam utilizando o JPDA (Java Platform Debugger Architecture) fornecido pelo SDK para Linux.  JDB (Java Debugger) O JDB (Java Debugger) é incluído no SDK para Linux. O depurador é chamado pelo comando jdb; ele "conecta-se" à JVM utilizando o JPDA. Para depurar um aplicativo Java: Inicie a JVM com as seguintes opções: java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=   MyApp A JVM é iniciada, porém suspende a execução antes de iniciar o aplicativo Java. Em uma sessão separada, você pode conectar o depurador à JVM: jdb -attach O depurador será conectado à JVM e você, agora, poderá emitir uma série de comandos para examinar e controlar o aplicativo Java; por exemplo, digite run para permitir a execução do aplicativo Java.  Para obter mais informações sobre as opções do JDB, digite: jdb -helpPara obter mais informações sobre os comandos do JDB: Digite jdbNo prompt do jdb, digite help  O JDB também pode ser utilizado para depurar aplicativos JDB em JPDA de máquinas remotas que utilizem um soquete TCP/IP para se conectar à JVM remota.  Inicie a JVM como antes.Conecte o depurador à máquina remota: jdb -attach : Ao ativar uma sessão de depuração utilizando o transporte dt_socket, verifique se as portas especificadas estão livres para utilização.  |A JVMDI (Java Virtual Machine Debugging Interface) |não é suportada neste release. Ela foi substituída pela JVMTI (Java |Virtual Machine Tool Interface).  Para obter mais informações sobre o JDB e o JPDA e seu uso, consulte estes Web sites:  http://java.sun.com/products/jpda/http://java.sun.com/j2se/1.5.0/docs/guide/jpda/http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdb.html Determinando se o Aplicativo Está Sendo Executado em uma JVM de 32 ou 64 bits  Alguns aplicativos Java devem ser capazes de determinar se estão sendo executados em uma JVM de 32 ou de 64 bits. Por exemplo, se o aplicativo tiver uma biblioteca de códigos nativos, ela deverá ser compilada separadamente nos formatos 32 e 64 bits das plataformas que suportam ambos os modos de operação, 32 e 64 bits. Nesse caso, seu aplicativo deverá carregar a biblioteca correta no tempo de execução, pois não será possível misturar código de 32 e 64 bits.  A propriedade de sistema com.ibm.vm.bitmode permite que os aplicativos determinem o modo em que a JVM está executando. Ela retorna os seguintes valores:  32 - a JVM está executando no modo de 32 bits64 - a JVM está executando no modo de 64 bitsVocê pode verificar o com.ibm.vm.bitmode a partir do código do aplicativo utilizando a chamada: System.getProperty("com.ibm.vm.bitmode");  Escrevendo Aplicativos JNI Os números de versão válidos do JNI que os programas nativos podem especificar na chamada de API JNI_CreateJavaVM() são: JNI_VERSION_1_2(0x00010002)JNI_VERSION_1_4(0x00010004)Esse número de versão determina somente o nível da interface nativa do JNI a ser utilizada. O nível real da JVM criado é especificado pelas bibliotecas J2SE (isto é, v5.0). A API da interface do JNI não afeta a especificação de idioma implementada pela JVM, as APIs da biblioteca de classes ou qualquer outra área do comportamento da JVM.  Para obter informações adicionais, consulte http://java.sun.com/j2se/1.5.0/docs/guide/jni. Se seu aplicativo precisar de duas bibliotecas do JNI, uma criada para 32 bits e outra para 64 bits, utilize a propriedade do sistema com.ibm.vm.bitmode para determinar se está executando com uma JVM de 32 bits ou 64 bits e escolha a biblioteca de propriedades.  Para compilar e vincular um aplicativo nativo com o IBM 5.0 SDK, utilize o seguinte comando: gcc -I/opt/ibm/java2-i386-50/include -L/opt/ibm/java2-i386-50/jre/bin/j9vm-ljvm -ldl -lpthread A opção -ljvm especifica se libjvm.so é a biblioteca compartilhada que implementa a JVM. A opção -lpthread indica que você está utilizando o suporte pthread nativo; se não vincular com a biblioteca pthread, um falha na segmentação (sinal SIGSEGV) poderá ocorrer quando você executar o programa JNI.  Nota: A Versão 1.1 do JNI (Java Native Interface) não é suportada.| | |Suporte para Recuperação de Nível de Encadeamento de Conectores Bloqueados |Quatro novas classes SDK específicas da IBM foram incluídas no pacote com.ibm.jvm |para suportar a recuperação de nível de encadeamento de conectores bloqueados. As novas classes |estão em pacotes no core.jar. |Essas classes permitem que você desbloqueie os encadeamentos que ficaram bloqueados |nas chamadas em rede ou de sincronização. Se um aplicativo não utilizar essas |classes, ele deverá finalizar o processo inteiro, em vez de interromper um encadeamento |bloqueado individual.  |As classes são: ||Interface pública InterruptibleContext() |Define dois métodos, isblocked() e unblock(). As outras três classes |implementam InterruptibleContext. | |classe pública InterruptibleLockContext() |É uma classe do utilitário para interromper as chamadas de sincronização. | |classe pública InterruptibleIOContext() |É uma classe do utilitário para interromper as chamadas de rede. | |classe pública InterruptibleThread() |É uma classe do utilitário que estende java.lang.Thread, para permitir agrupamento |de métodos executáveis que podem ser interrompidos. Ela utiliza instâncias de InterruptibleLockContext |e InterruptibleIOContext para executar os métodos isblocked() e unblock() |necessários dependendo se uma operação de sincronização ou rede estiver |bloqueando o encadeamento.  | | |Ambos InterruptibleLockContext e InterruptibleIOContext funcionam de acordo |com o encadeamento atual. Portanto, se você não utilizar InterruptibleThread, deverá |fornecer sua própria classe que estende java.lang.Thread, para utilizar essas novas classes. |O Javadoc para essas classes é fornecido com o SDK no arquivo docs/apidoc.zip.  Trabalhando com Applets Com o Applet Viewer, você pode executar um ou mais applets que sejam chamados pela referência em uma página da Web (arquivo HTML) utilizando a tag APPLET. O Applet Viewer localiza as tags APPLET no arquivo HTML e executa os applets, em janelas separadas, como especificado pelas tags. Como o Applet Viewer destina-se à visualização de applets, ele não pode exibir uma página da Web inteira que contenha muitas tags HTML. Ele analisa apenas as tags APPLET e nenhum outro HTML na página da Web.  Executando Applets com o Applet Viewer Para executar um applet com o Applet Viewer, digite o seguinte em um prompt de comandos :    appletviewer nome em que nome é uma das seguintes opções: O nome de um arquivo HTML que chama um appletA URL de uma página da Web que chama um applet Por exemplo, para chamar o Applet Viewer em um arquivo HTML que chama um applet, digite em um prompt de comandos :    appletviewer $HOME/nome do arquivo.html em que nome do arquivo é o nome do arquivo HTML.  Por exemplo, http://java.sun.com/applets/NervousText/example1.html é a URL de uma página da Web que chama um applet. Para chamar o Applet Viewer nessa página da Web, digite em um prompt shell:  appletviewer http://java.sun.com/applets/NervousText/example1.html  O Applet Viewer não reconhece a opção charset da tag . Se o arquivo que o appletviewer carregar não for codificado como o padrão do sistema, poderá ocorrer uma exceção de E/S. Para evitar a exceção, utilize a opção -encoding ao executar o appletviewer.  Exemplo:  appletviewer -encoding JISAutoDetect sample.html  Depurando Applets com o Applet Viewer É possível depurar applets utilizando a opção -debug do Applet Viewer. Ao depurar applets, será recomendado que você chame o Applet Viewer do diretório que contém o arquivo HTML que chama o applet. Exemplo:  cd demo/applets/TicTacToe../../bin/appletviewer -debug example1.html A documentação sobre como depurar applets utilizando o Applet Viewer pode ser localizada no Web site da Sun: http://java.sun.com.| | |Configurando a Alocação da Memória de Página Grande |É possível ativar o suporte a páginas grandes, nos sistemas com suporte |para tal, iniciando o Java com a opção -Xlp.  |O uso da página grande é pretendido principalmente para fornecer melhorias de desempenho |para aplicativos que aloquem muita memória e freqüentemente acessem essa memória. |As melhorias de desempenho de página grande são ocasionadas principalmente pelo número reduzido |de falhas no TLB (Translation Lookaside Buffer). Os TLB mapeia um intervalo maior |de memória virtual e, portanto, causa esse aprimoramento.  |O suporte de página grande deve estar disponível no kernel, e ativado, para permitir |que o Java utilize páginas grandes.  |Para configurar a alocação de memória de página grande, primeiro certifique-se de que o kernel |que está sendo executado suporta páginas grandes. Verifique se o arquivo /proc/meminfo contém as |seguintes linhas:  |HugePages_Total:     |HugePages_Free:      |Hugepagesize:        O número de páginas disponíveis |e seus tamanhos varia entre as distribuições.  |Se o suporte de página grande não estiver disponível no kernel, essas linhas |não existiram no arquivo /proc/meminfo.  Neste caso, você deverá instalar um novo |kernel que contenha o suporte para páginas grandes.  |Se o suporte de página grande estiver disponível, mas não ativado, HugePages_Total será 0.  Neste caso, seu administrador deverá ativar o suporte de página |grande. Verifique o manual do seu sistema operacional para obter mais instruções.  |Para que a JVM utilize páginas grandes, seu sistema deverá ter um número adequado |de páginas grandes contíguas disponíveis. Se, mesmo quando há paginas |suficientes disponíveis, não foi possível alocar páginas grandes, |possivelmente as páginas grandes não são contíguas.Configurar o número de página grandes no bootup as criará de modo |contíguo.  |As alocações de páginas grandes terão êxito somente se a JVM tiver acesso root. Para utilizar as páginas |grandes, você pode executar o Java como raiz ou definir o suid bit do Java executável.  Suporte ao CORBA O Java 2 Platform, Standard Edition (J2SE) suporta, pelo menos, as especificações definidas em Official Specifications for CORBA support in J2SE (V1.5). Em alguns casos, o IBM J2SE ORB suporta as versões mais recentes das especificações.  Suporte para GIOP 1.2 Este SDK suporta todas as versões de GIOP, como definido nos capítulos 13 e 15 da especificação do CORBA 2.3.1, documento OMG formal/99-10-07, o qual pode ser obtido em: http://www.omg.org/cgi-bin/doc?formal/99-10-07 O GIOP bidirecional não é suportado.  Suporte para Interceptadores Portáteis Este SDK suporta Interceptadores Portáteis, como definido pelo OMG no documento ptc/01-03-04, o qual pode ser obtido em: http://www.omg.org/cgi-bin/doc?ptc/01-03-04 Os Interceptadores Portáteis são ganchos para o ORB por meio dos quais os serviços ORB podem interceptar o fluxo normal de execução do ORB.  Suporte para Serviço de Nomes Interoperável Este SDK suporta o Serviço de Nomes Interoperável, como definido pelo OMG no documento ptc/00-08-07, o qual pode ser obtido em: http://www.omg.org/cgi-bin/doc?ptc/00-08-07 A porta padrão utilizada pelo Servidor de Nomes Transientes (o comando tnameserv), quando nenhum parâmetro ORBInitialPort é fornecido, foi alterada de 900 para 2809, que é o número da porta registrado no IANA (Internet Assigned Number Authority) para um Serviço de Nomes do CORBA. Os programas que dependem desse padrão podem precisar ser atualizados para funcionarem com esta versão.  O contexto inicial retornado do Servidor de Nomes Transientes agora é org.omg.CosNaming.NamingContextExt. Os programas existentes que reduzem a referência a um contexto org.omg.CosNaming.NamingContext ainda funcionam e não precisam ser recompilados.  O ORB suporta os parâmetros -ORBInitRef e -ORBDefaultInitRef que são definidos pela especificação do Serviço de Nomes Interoperável; a operação ORB::string_to_object agora suporta os formatos de cadeia ObjectURL (corbaloc: e corbaname:) que são definidos pela especificação do Serviço de Nomes Interoperável.  O OMG especifica um método ORB::register_initial_reference para registrar um serviço no Serviço de Nomes Interoperável. No entanto, esse método não está disponível na API do Sun Java Core em Versão 5.0. Os programas que precisam registrar um serviço na versão atual devem chamar esse método na classe de implementação do ORB interno da IBM. Por exemplo, para registrar um serviço "MyService":  ((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MyService",serviceRef);  em que orb é uma instância de  org.omg.CORBA.ORB, retornada de ORB.init() , e serviceRef é um objeto CORBA, conectado ao ORB. Esse é um mecanismo intermediário, e não é compatível com versões futuras ou portáteis para ORBs não-IBM.   Propriedades do Sistema para Rastrear o ORB Um recurso de depuração de tempo de execução fornece capacidade de utilização aprimorada. Você pode considerá-lo útil para diagnóstico de problemas ou ele pode ser solicitado pela equipe de serviços da IBM. O rastreio é controlado por três propriedades de sistema.  Para ativar o rastreio, defina com.ibm.CORBA.Debug=true .Para formatar e incluir nas mensagens GIOP de rastreio enviadas e recebidas, defina com.ibm.CORBA.CommTrace=true. Por padrão, o rastreio ORB busca arquivos que possuem nomes no formato orbtrc.DDMMYYYY.HHmm.SS.txt.Para enviá-lo para um outro arquivo, defina com.ibm.CORBA.Debug.Output=.  Por exemplo, para rastrear eventos e mensagens GIOP formatadas, digite:  java -Dcom.ibm.CORBA.Debug=true		-Dcom.ibm.CORBA.CommTrace=true myapp     Não ative o rastreio para operação normal, pois ele pode causar degradação no desempenho. Mesmo que você tenha desativado o rastreio, o FFDC (First Failure Data Capture) ainda funciona, de forma que apenas os erros sérios sejam relatados. Se um arquivo de saída de depuração for gerado, examine-o para analisar o problema. Por exemplo, o servidor pode ter parado sem executar um ORB.shutdown(). O conteúdo e o formato da saída de rastreio variam de acordo com a versão.  Propriedades do Sistema para Ajustar o ORB As seguintes propriedades ajudam você a ajustar o ORB: Para controlar a fragmentação do GIOP 1.2, defina a propriedade de sistema com.ibm.CORBA.FragmentSize. Por exemplo, para definir o tamanho do fragmento para 4096 bytes: java -Dcom.ibm.CORBA.FragmentSize=4096 myapp O tamanho padrão do fragmento é 1024 bytes. Você pode desativar a fragmentação definindo o tamanho do fragmento como 0. Em uma rede heterogênea, a resposta para um Pedido CORBA pode ser retardada ou perdida. Você pode definir o tempo máximo de espera utilizando a propriedade de sistema com.ibm.CORBA.RequestTimeout. Pode também utilizar com.ibm.CORBA.LocateRequestTimeout para controlar o tempo limite para LocateRequests. Por exemplo, para restringir ambos os retardos para 30 segundos, digite: java -Dcom.ibm.CORBA.RequestTimeout=30   -Dcom.ibm.CORBA.LocateRequestTimeout=30 myapp Por padrão, o ORB aguarda indefinidamente por uma resposta. Para impedir que as conexões sejam encerradas desnecessariamente, não defina um valor muito baixo para o tempo limite. Se seu programa estiver fornecendo um serviço na rede, poderá ser necessário definir, para um valor conhecido, o número da porta da qual o ORB lê os pedidos recebidos. Isso pode ser controlado utilizando a propriedade de sistema com.ibm.CORBA.ListenerPort.  Por exemplo, para que o ORB utilize a porta 1050, digite: java -Dcom.ibm.CORBA.ListenerPort=1050 myapp Se essa propriedade for definida, o ORB começará a atender assim que for inicializado. Caso contrário, ele começará a atender somente quando for solicitado.   Permissões de Segurança do Java 2 para o ORB Ao executar um Java 2 SecurityManager, a chamada de alguns métodos nas classes de API do CORBA pode fazer com que seja feita verificações de permissões, o que pode resultar em um SecurityException. Os métodos afetados incluem o seguinte:    Tabela 2. Métodos afetados ao executar com o Java 2 SecurityManager   Classe/Interface Método Permissão Necessária      org.omg.CORBA.ORB  init  java.net.SocketPermission resolve    org.omg.CORBA.ORB  connect  java.net.SocketPermission listen    org.omg.CORBA.ORB  resolve_initial_references  java.net.SocketPermission connect    org.omg.CORBA.portable.ObjectImpl  _is_a  java.net.SocketPermission connect    org.omg.CORBA.portable.ObjectImpl  _non_existent  java.net.SocketPermission connect    org.omg.CORBA.portable.ObjectImpl  OutputStream _request (String, boolean)  java.net.SocketPermission connect    org.omg.CORBA.portable.ObjectImpl  _get_interface_def  java.net.SocketPermission connect    org.omg.CORBA.Pedido  invoke  java.net.SocketPermission connect    org.omg.CORBA.Pedido  send_deferred  java.net.SocketPermission connect    org.omg.CORBA.Pedido  send_oneway  java.net.SocketPermission connect    javax.rmi.PortableRemoteObject  narrow  java.net.SocketPermission connect    Se seu programa utilizar qualquer um desses métodos, assegure-se de que ele tenha as permissões necessárias.   Classes de Implementação do ORB As classes de implementação do ORB neste release são: org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORBorg.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingletonjavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.UtilDelegateImpljavax.rmi.CORBA.StubClass=com.ibm.rmi.javax.rmi.CORBA.StubDelegateImpljavax.rmi.CORBA.PortableRemoteObjectClass=  com.ibm.rmi.javax.rmi.PortableRemoteObject Esses são os valores padrão e é aconselhável que você não defina essas propriedades ou faça referência às classes de implementação diretamente.  Para obter portabilidade, faça referência somente às classes de API do CORBA e não à implementação. Esses valores podem ser alterados em releases futuros.   RMI sobre IIOP O Java RMI (Remote Method Invocation) fornece um mecanismo simples para executar a programação Java distribuída. O RMI sobre IIOP (RMI-IIOP) utiliza o protocolo IIOP (Internet Inter-ORB) padrão do CORBA (Common Object Request Broker Architecture) para estender o Java RMI base para executar a comunicação. Isso permite direcionar a interação com quaisquer outros ORBs (Object Request Brokers) do CORBA, independentemente de terem sido implementados no Java ou em outra linguagem de programação.  A seguinte documentação está disponível: O Guia do Programador do RMI-IIOP é uma introdução para escrever programas RMI-IIOP. O guia é instalado quando você instala esta documentação.O diretório demo  contém: Um exemplo "Hello World" que pode alternar entre o JRMP (Java Remote Method Protocol) e os protocolos IIOP (demo/rmi-iiop/hello)Um exemplo "Hello World" que interage com um programa IDL padrão (demo/rmi-iiop/idl)O documento Linguagem Java para Mapeamento IDL é uma especificação técnica detalhada do RMI-IIOP e pode ser encontrado em:http://www.omg.org/cgi-bin/doc?ptc/00-01-06.pdf   Implementando o Conjunto da Rotina de Tratamento de Conexão para RMI O conjunto de encadeamento para as Rotinas de Tratamento de Conexão do RMI não é ativado por padrão. Para ativar o conjunto de conexão implementado no nível TCPTransport do RMI, defina a opção  -Dsun.rmi.transport.tcp.connectionPool=true (ou qualquer valor que não seja nulo) Essa versão do Runtime Environment não possui nenhuma definição que você possa utilizar para limitar o número de encadeamentos no conjunto de conexão. Para obter informações adicionais, consulte o site do Java da Sun: http://java.sun.com.  Suporte ao BiDirectional Avançado O IBM SDK inclui suporte ao BiDirectional avançado. Para obter mais informações, consulte http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html.O Javadoc para o pacote BiDirectional é fornecido com o SDK no arquivo docs/apidoc.zip.  BigDecimal Avançado| |No Java 5.0, a classe IBM BigDecimal foi adotada pela Sun como java.math.BigDecimal. | A IBM não mantém mais o com.ibm.math.BigDecimal e está sinalizado como desaprovado. | Recomenda-se migrar o código Java existente para utilizar o java.math.BigDecimal. |O novo java.math.BigDecimal utiliza os mesmos métodos que o |java.math.BigDecimal e o com.ibm.math.BigDecimal anteriores.  O código existente que utiliza o java.math.BigDecimal |continua funcionando corretamente. |Para migrar o código Java existente para utilizar a classe java.math.BigDecimal, altere |a instrução de importação no início do arquivo java de: importar com.ibm.math.*; para importar java.math,*;.  Suporte ao Símbolo Euro O IBM SDK and Runtime Environment define   o Euro como a moeda padrão para os países da EMU (União Monetária Européia) para datas em ou após 1º de janeiro de 2002. Para utilizar a moeda nacional antiga, especifique -Duser.variant=PREEURO na linha de comandos Java. Se você estiver executando os códigos do idioma inglês (Reino Unido), dinamarquês ou suéco e desejar utilizar o Euro, especifique -Duser.variant=EURO na linha de comandos Java.  Utilizando o Java Communications API (JavaComm) O pacote do Java Communications API (Application Programming Interface) (JavaComm) é um pacote opcional fornecido para ser utilizado com o Runtime Environment para Linux nas plataformas IA32, PPC32/PPC64 e AMD64/EM64T. Instale o JavaComm independentemente do SDK ou Runtime Environment. O JavaComm API fornece aos aplicativos Java uma forma independente de plataforma de executar comunicações das portas seriais e paralelas para tecnologias como correio de voz, fax e cartões inteligentes. Depois de gravar as comunicações das portas seriais e paralelas para seus aplicativos, inclua esses arquivos em seu aplicativo. O Java Communications API suporta as portas seriais Electronic Industries Association (EIA)-232 (RS232) e as portas paralelas Institute of Electrical and Electronics Engineers (IEEE) 1284; ela é suportada em sistemas que tenham o IBM Runtime Environment, Version 5.0. Utilizando o Java Communications API, você pode: Listar portas em um sistemaAbrir e reivindicar direito à propriedade de portasResolver contenção de direito à propriedade de porta entre aplicativos que utilizam o Java Communications APIExecutar monitoração de porta de E/S assíncrona e síncrona por meio de notificação de eventosReceber eventos de estilo bean que descrevem as alterações de estado da porta  Instalando o Java Communications API Você precisa certificar-se de que uma cópia do SDK ou Runtime Environment esteja instalada antes de instalar o Java Communications API. Se você utilizou o pacote de RPM para instalar o Java originalmente, instale o Java Communications API a partir do arquivo RPM. Para instalar o Java Communications API de um pacote de RPM: Abra um prompt de shell e certifique-se de que seja root. Utilizando o comando rpm -ivh, instale o arquivo RPM do Java Communications API. Exemplo: rpm -ivh ibm-java2--javacomm-5.0-0.0..rpm O Java Communications API é instalado na estrutura de diretório /opt/ibm/java2-i386-50/.  Para instalar o Java Communications API de um arquivo zip .tgz file: Coloque o arquivo archive do Java Communications API, ibm-java2-javacomm-50-linux-.tgz, no diretório que contém o diretório IBMJava2-50. Em um prompt de shell, no diretório que contém o arquivo .tgz, extraia o conteúdo: tar -xvzf ibm-java2-javacomm-50-linux-.tgz O Java Communications API é extraído em subdiretórios no diretório IBMJava2-50 existente.   Local dos Arquivos do Java Communications API Os arquivos do Java Communications API estão instalados como mostrado: jre/lib/ext/comm.jarjre/bin/libibmcomm.sojre/lib/javax.comm.properties Se você instalou no diretório padrão, o arquivo comm.jar está em /opt/ibm/java2-i386-50/jre/lib/ext. Se instalou o pacote em outro diretório, os arquivos estão na mesma estrutura de diretório, porém /opt/ibm/java2-i386-50/ é substituído pelo diretório em que o Java Communications API foi instalado.  Configurando o Java Communications API Depois de instalar o Java Communications API, é necessário: Alterar o modo de acesso das portas seriais e paralelas.Definir o PATH, se você não o definiu quando instalou o Java. Consulte Definindo o PATH.  Alterando o Modo de Acesso das Portas Seriais e Paralelas Depois de instalar o Java Communications API, você terá que alterar o modo de acesso das portas seriais e paralelas para que os usuários possam acessar esses dispositivos. Terá que fornecer um acesso de leitura/gravação aos dispositivos requeridos. Efetue logon como root e utilize os seguintes comandos, conforme aplicável:      chmod 666 /dev/ttyS0    (também conhecido como porta serial COM1)  chmod 666 /dev/lp0      (também conhecido como porta paralela LPT1)  chmod 666 /dev/ttyS1    (também conhecido como porta serial COM2)  chmod 666 /dev/ttyS2    (também conhecido como porta serial COM3)  chmod 666 /dev/ttyS3    (também conhecido como porta serial COM4) Esses comandos fornecem acesso de leitura/gravação a qualquer pessoa que esteja utilizando o sistema. Um método alternativo é criar as permissões 660 e incluir usuários específicos no grupo em que os dispositivos residem. Em um sistema SUSE, por exemplo, os dispositivos estão no grupo uucp. Portanto, os usuários podem ser incluídos no grupo uucp para obter acesso aos dispositivos.  Altere o modo de acesso de qualquer outra porta, conforme necessário.   Especificando Dispositivos no Arquivo javax.comm.properties O arquivo javax.comm.properties permite que você especifique os prefixos dos dispositivos que se tornam disponíveis para o Java Communications API e se são paralelos ou seriais. Os números de porta são alocados seqüencialmente para todos os dispositivos. Por exemplo, se você especificar /dev/ttyS=PORT_SERIAL e os dispositivos /dev/ttyS0 e /dev/ttyS1 existirem, eles serão alocados COM1 e COM2 respectivamente. Para utilizar os conectores USB-serial, remova o comentário da linha /dev/ttyUSB=PORT_SERIAL no arquivo javax.comm.properties. Se os dispositivos /dev/ttyUSB0 e /dev/ttyUSB1 existirem e COM1 e COM2 já foram definidos, os dispositivos USB-serial serão alocados para as próximas portas seqüenciais, COM3 e COM4.  Ativando Portas Seriais no IBM ThinkPads Por padrão, a maioria dos ThinkPads têm as portas seriais desativas no BIOS. Atualmente, não há uma maneira de ativar as portas com o Linux (o pacote tpctl não ativará as portas se elas estiverem desativadas no BIOS).  Para ativar as portas no BIOS, você precisa utilizar a versão DOS do ThinkPad Configuration Utility que está disponível no site do IBM ThinkPad Download. Para utilizar o ThinkPad Configuration Utility, é necessário ter um disquete DOS inicializável. Observe que o ThinkPad Configuration Utility pode ter sido instalado como parte do ThinkPad Utilities no Windows, dependendo das opções de instalação, e você poderá executá-lo a partir do prompt de comandos no Windows. O aplicativo ThinkPad Configuration fornecido com o Windows possui opções para ativar ou desativar as portas seriais ou paralelas, porém isso tampouco altera as configurações no BIOS. Portanto, se você utilizar esse aplicativo com o Windows, as portas ficarão disponíveis; contudo, se você reinicializar sua máquina com o Linux, as portas não serão ativadas.   Limitação ao Imprimir com o Java Communications API Ao imprimir com o Java Communications API, poderá ser necessário pressionar "Avanço do Papel", "Continuar" ou similar na impressora.   Desinstalando o Java Communications API O processo que você utiliza para desinstalar o Java Communications API depende se você instalou o pacote RPM (Red Hat Package Manager) instalável ou o pacote TAR (Tape Archive) compacatado.   Desinstalando o Pacote RPM (Red Hat Package Manager) Instalável Para desinstalar o Java Communications API se você instalou o pacote RPM instalável: Em um prompt de shell, digite:        rpm -e ibm-java2--javacomm-5.0-0.0 Como alternativa, você pode utilizar uma ferramenta gráfica como kpackage ou yast2. Se o diretório em que o Java Communications API foi instalado não contiver nenhuma outra ferramenta que você precise, remova esse diretório da instrução PATH.  Desinstalando o Pacote TAR (Tape Archive) Compactado Para desinstalar o Java Communications API, se você instalou o pacote TAR compactado, exclua os seguintes arquivos do diretório em que foram instalados: jre/lib/ext/comm.jarjre/bin/libibmcomm.sojre/lib/javax.comm.properties  Documentação do Java Communications API A documentação da API e as amostras do Java Communications API podem ser localizadas no Web site da Sun: http://java.sun.com.  Implementando os Aplicativos Java  (Linux IA de 32 bits e PPC32 apenas) Utilizando o Plug-in Java O Plug-in Java é um plug-in de navegador da Web. Ao utilizar o Java Plug-in, você pode ignorar a JVM padrão de seu navegador da Web e utilizar um Runtime Environment de sua preferência para executar os applets ou beans no navegador. É necessário permitir o término do carregamento dos applets para evitar que o navegador seja 'interrompido'. Por exemplo, se você utilizar o botão Voltar e depois o botão Avançar enquanto um applet estiver sendo carregado, pode ser que as páginas HTML não sejam carregadas.  O Java Plug-in é documentado pela Sun em: http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.  Navegadores Suportados |Para Linux PPC32, o Mozilla 1.6 é o navegador suportado.  |Para Linux IA32, consulte Tabela 3.   |Tabela 3. Navegadores suportados pelo Java Plug-in no Linux IA32   |Distribuição |Versão Padrão do Netscape |Versões suportadas do Netscape |Versão Padrão do Mozilla |Versões suportadas do Mozilla     |Red Hat Enterprise Linux 3.0 |- |7.x |1.4.2 |1.4.1, 1.4.2, 1.7.8, Firefox 1.0.x   |Red Hat Enterprise Linux 4.0 |4.8 |7.x |1.7.3 |1.4.1, 1.4.2, 1.7.8, Firefox 1.0.x   |SUSE Linux Enterprise Server 9.0 |- |7.x |1.6 |1.4.1, 1.4.2, 1.6, 1.7.8, Firefox 1.0.x   |  Instalando e Configurando o Plug-in Java |Várias versões do Java Plug-in são fornecidas com o SDK. Escolha a versão |correta para seu navegador. Os mais comuns |são: | |libjavaplugin_oji.so |O Plug-in mais comum. Baseia-se na iniciativa Open JVM Integration do Mozilla e é utilizado como a maioria dos |produtos e derivados Mozilla, inclusive o Firefox.  | |libjavaplugin_ojigtk2.so |O mesmo Plug-in de acima, mas compilado com o toolkit GTK2. | |Há instruções para instalar o Plug-in em alguns navegadores comuns |abaixo.  |Vincule simbolicamente o Plug-in, em vez de copiá-lo, de forma que |seja possível localizar a JVM.   Mozilla |Apenas o Mozilla versões 1.4 e posteriores é suportado. Para disponibilizar o Plug-in Java para todos os usuários:  Efetue login como root.Altere o diretório de Plug-ins Mozilla (isso pode ser diferente em algumas distribuições do Linux).  cd /usr/local/mozilla/plugins/|Crie um link simbólico para libjavaplugin_oji.so. |ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .Vincule simbolicamente o Plug-in, em vez de copiá-lo, de forma que seja possível localizar a JVM. | | |Firefox |Para disponibilizar o Plug-in Java para todos os usuários:  ||Efetue login como root.|Altere o diretório de Plug-ins Firefox (isso pode ser diferente em algumas |distribuições do Linux).  |cd /usr/local/mozilla-firefox/plugins/||Crie um link simbólico para libjavaplugin_oji.so. |ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .|Vincule simbolicamente o Plug-in, em vez de copiá-lo, de forma que |seja possível localizar a JVM.   Netscape 7.1 e posterior Para instalar e configurar o Java Plug-in para Netscape, crie um link simbólico do arquivo de biblioteca /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so para o diretório de Plug-ins do navegador (/browser-install-path/plugins). Efetue login como root.Altere o diretório de Plug-ins Netscape (isso pode ser diferente em algumas distribuições do Linux).  cd /usr/local/netscape/plugins/Coloque um link simbólico para o javaplugin_oji.so no diretório do Plug-in.  ln -s /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so .Vincule simbolicamente o Plug-in, em vez de copiá-lo, de forma que seja possível localizar a JVM.   Suporte a DOM (Document Object Model) Por causa das limitações em determinados navegadores, você talvez não consiga implementar todas as funções do pacote org.w3c.dom.html. Uma sun.plugin.dom.exception.NotSupportedException é lançada para algumas dessas funções.Uma sun.plugin.dom.exception.InvalidStateException é lançada quando o navegador não suporta um função específica.  Utilizando Parâmetros DBCS O Java Plug-in suporta caracteres de byte duplo (por exemplo, chinês tradicional BIG-5, coreano, japonês) como parâmetros para as marcações ,    e . Será necessário selecionar a codificação de caractere correta para seu documento HTML, para que o Plug-in Java possa analisar o parâmetro. Especifique a codificação de caracteres para o documento HTML utilizando a marcação  na seção  desta forma: Esse exemplo pede que o navegador utilize a codificação de caracteres Chinese BIG-5 para analisar a utilização do arquivo HTML. Todos os parâmetros são aprovados para o Plug-in Java corretamente. No entanto, algumas das versões mais antigas dos navegadores podem não interpretar essa marcação corretamente. Nesse caso, você poderá fazer com que o navegador ignore essa marcação, mas poderá ter de alterar a codificação manualmente. Você poderá especificar qual codificação você deseja utilizar para analisar o arquivo HTML:  Netscape 4: Exibir Menu -> Conjunto de Caracteres Mozilla: Exibir Menu -> Código de Caractere   Utilizando Web Start (Somente Linux IA 32 bits, PPC32 e PPC64) Você pode utilizar o Java Web Start para implementar os aplicativos Java.  O Web Start permite que o usuário ative e gerencie aplicativos diretamente da Web. Com o Java Web Start, você pode iniciar aplicativos facilmente da Web, certo de que esteja executando a versão mais recente, eliminando procedimentos de instalação ou upgrade.  O Java Web Start elimina a necessidade de fazer download e instalar software, ignorando as opções de instalação demoradas.  |Além do java-vm-args documentado em http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources, o Web Start suporta -Xgcpolicy para definir a política de |coleta de lixo.  Para obter informações sobre os navegadores que suportam o Web Start, consulte Navegadores Suportados. Para obter mais informações sobre o Web Start, consulte: http://java.sun.com/products/javawebstart e http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Para obter mais informações sobre os aplicativo de implementação, consulte: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.  Executando o Web Start  O Java Web Start v5.0 é instalado automaticamente quando você instala o Java utilizando os pacotes .rpm ou .tgz. |Ao extrair o Java do pacote .tgz, execute o script shell jre/lib/javaws/updateSettings.sh, |para atualizar os arquivos .mailcap e .mime.types em seu sistema. Você pode chamar o Web Start de três maneiras: Selecione um link em uma página da Web que faça referência a um arquivo .jnlp.Em um prompt de shell, digite javaws , onde  é o local de um arquivo .jnlp.|Se o Java Web Start já foi utilizado para abrir o aplicativo, execute |javaws, no |diretório jre/bin,para ativar o Java Application Cache Viewer.  Depois de fazer download do aplicativo, ele será armazenado no Java Application Cache. Se o aplicativo for acessado novamente, o Java Web Start fará download de uma versão mais recente do aplicativo, se estiver disponível, e utilizará a versão em cache, se não estiver disponível. Se ocorrer um erro em um arquivo .jnlp (como um nome de tag inválido), o Web Start falhará sem exibir uma mensagem de erro.   Remessa dos Aplicativos Java   Um aplicativo Java, ao contrário de um applet Java, não pode contar com um navegador da Web para serviços de instalação e tempo de execução. Quando você envia um aplicativo Java, o pacote de software provavelmente consiste nas seguintes partes:  Sua própria classe, recurso e arquivos de dadosUm procedimento ou programa de instalação Para executar o aplicativo, um usuário precisa do Runtime Environment para Linux.  O software SDK para Linux contém um Runtime Environment. No entanto, você não pode assumir que os usuários tenham o software SDK para Linux instalado. A licença do software SDK para Linux não permite que você redistribua qualquer um dos arquivos do SDK com seu aplicativo. Você precisa assegurar-se de que uma versão licenciada do SDK para Linux esteja instalada na máquina de destino. | | |Compartilhamento de Dados de Classe Entre JVMs |O IBM Virtual Machine (VM) permite compartilhar classes de auto-inicialização e |aplicativos entre VMs, armazenando-as em um cache na memória compartilhada. O compartilhamento de classes |reduz o consumo geral de memória virtual quando mais de uma VM compartilha |um cache. O compartilhamento de classe também reduz o tempo de inicialização de uma VM depois do cache |ter sido criado. O cache de classe compartilhada é independente de qualquer VM ativo |e persiste além do período de existência da VM que iniciou o cache. | |Visão Geral sobre o Compartilhamento de Classe |O IBM SDK permite compartilhar tantas classes quanto possível, atuando |de forma transparente ao usuário.  | |Conteúdo do Cache |O cache de classe compartilhada contém dados e metadados da classe estática de leitura |que descreve as classes. Qualquer VM pode ler ou atualizar o cache. Os VMs que |estão sendo compartilhados devem estar no mesmo release. Você deve tomar |cuidado se o bytecode do tempo de execução estiver sendo utilizado. (Consulte Modificação do Bytecode de Tempo de Execução).  | |Atualização Dinâmica do Cache |Como o cache de classe compartilhada persiste além do período de existência de qualquer VM, |o cache é atualizado dinamicamente para refletir quaisquer modificações que possam ter sido |feitas nos JARs ou nas classes, no sistema de arquivos. A atualização dinâmica torna |o cache transparente para o aplicativo que está utilizando-o. | |Ativando o Compartilhamento de Classe |Ative o compartilhamento de classes utilizando a opção -Xshareclasses |ao iniciar uma VM, para fazer com que a VM se conecte a um cache existente ou crie |um se ainda não existir. Todas as classes de auto-inicialização e aplicativos carregadas pela VM são compartilhadas por padrão. Os carregadores de classe personalizados são compartilhados automaticamente se |estenderem o carregador de classe do aplicativo; caso contrário, eles deverão usar o Java Helper |API fornecido com a VM para acessar o cache. (Consulte Adaptando Carregadores de Classe Personalizados às Classes de Compartilhamento).  | |Segurança do Cache |A acesso ao cache de classe compartilhada é limitado pelas permissões |do sistema operacional e da segurança do Java. Por padrão, |o cache de classe compartilhada será criado com o |acesso de usuário, exceto se a subopção da linha de comandos |groupAccess  for utilizada. Somente um classloader registrado para |compartilhar classes poderá incluir classes no cache de classe |compartilhada. Se um Java SecurityManager estiver instalado, os |ClassLoaders (exceto os de auto-inicialização, de aplicativo e de |extensão) devem possuir permissão para compartilhar classes, incluindo |SharedClassPermissions no arquivo java.policy. (Consulte Utilizando SharedClassPermissions). A |RuntimePermission "createClassLoader" restringe a criação de novos |ClassLoaders e, portanto, também restringe o acesso ao cache.  | |Tempo de Vida do Cache |Vários caches podem existir em um sistema e são especificados por nome como uma subopção |para o comando -Xshareclasses. Uma VM pode se conectar a apenas um cache |por vez. Especifique o tamanho do cache na inicialização utilizando -Xscmx[k|m|g], porém esse tamanho será corrigido para o período de existência do |cache. Os caches existirão até que sejam explicitamente destruídos utilizando uma subopção |para o comando -Xshareclasses ou até que o sistema seja |reinicializado.  | |Utilitários do Cache |Todos os utilitários do cache são subopções para o comando -Xshareclasses. Utilize -Xshareclasses:help para ver uma lista |de subopções disponíveis.  | |Utilizando as Opções da Linha de Comandos para Compartilhamento de Classe |O compartilhamento de classe é ativado e configurado utilizando as opções de linha de comandos -Xshareclasses e -Xscmx. ||-Xscmx<size>[k|m|g] ||Especifica o tamanho do cache. Essa opção é aplicável apenas se um cache |estiver sendo criado e se não houver nenhum cache existente com o mesmo |nome. |O tamanho do cache padrão depende da plataforma. |É possível descobrir o valor que está sendo utilizado, incluindo |-verbose:sizes  como argumento da linha de comando. O tamanho mínimo do |cache é 4 kB. O tamanho máximo do cache também depende da plataforma. (Consulte Limites no Tamanho do Cache).  |-Xshareclasses:<suboption1>[,<suboption2>...] ||Ativa o compartilhamento de classe. Pode obter um número de subopções, alguns dos quais |são utilitários de cache. Os utilitários de cache executam a operação requerida no |cache especificado, sem iniciar a VM. É possível combinar várias subopções, |separadas por vírgula, porém os utilitários de cache são mutuamente exclusivos. Você pode usar as seguintes subopções com a opção -Xshareclasses, por exemplo -Xshareclasses:help ||help ||Lista todas as opções da linha de comandos.|name=<name> ||Conecta a um cache de um determinado nome, criando o cache se ele ainda não |existir. Use a opção do utilitário listAllCaches |para mostrar quais caches estão atualmente disponíveis. Se não especificar |um nome, o nome padrão "sharedcc_" será combinado com o nome do usuário |atual anexado para criar o nome do cache. |groupAccess ||Define as permissões do sistema operacional num novo cache para permitir o |acesso do grupo ao cache. O padrão é acesso do usuário apenas. |verbose ||A opção Verbose fornece uma saída detalhada sobre a atividade de E/S do |cache, listando informações sobre as classes que estão sendo armazenadas e |localizadas. A cada carregador de classe é dado um único ID (o |carregador de auto-inicialização é sempre 0) e a saída mostra a hierarquia do carregador de classe |no trabalho, onde os carregadores de classe devem solicitar aos seus pais uma classe para poderem |carregá-la. É normal ver muitos pedidos com falha; esse comportamento é |esperado para a hierarquia do classloader. Observe que a opção padrão |-verbose:class também ativa a saída detalhada do |compartilhamento de classe, se tal compartilhamento estiver ativado. |modified=<modified context> ||Essa opção será requerida se for instalado um agente de bytecode que possa modificar |o bytecode no tempo de execução. Se você não especificar essa opção e um agente de bytecode |for instalado, nenhuma classe será armazenada ou localizada no cache. A opção  é um descritor escolhido pelo usuário; por exemplo, |"myModification1". Isso particiona o cache, de forma que apenas as JVMs que utilizem o contexto |myModification1 podem compartilhar as mesmas classes. Por exemplo, se você executar "HelloWorld" |com um contexto de modificação e depois executá-lo novamente com um contexto de modificação |diferente, verá todas as classes armazenadas duas vezes no cache.|destroy (opção do utilitário) ||Destrói um cache usando o nome especificado na subopção name=<name>. Se o nome não for especificado, |o cache padrão será destruído. Um cache somente pode ser destruído |se todos os VMs que o utilizam foram encerrados e o usuário tiver permissões suficientes. |destroyAll (opção do utilitário) ||Tenta destruir todos os caches disponíveis para o usuário. Um cache somente pode ser destruído |se todos os VMs que o utilizam foram encerrados e o usuário tiver permissões suficientes. |expire=<time in minutes> |(opção do utilitário) ||Destrói todos os caches que não foram utilizados durante o tempo especificado. |listAllCaches (opção do utilitário) ||Lista todos os caches no sistema, descrevendo se estão em uso e quando |foram utilizados pela última vez. |printStats (opção do utilitário) ||Exibe informações resumidas das estatísticas sobre o cache especificado na subopção name=<name>. Se o nome não for especificado, serão exibidas as estatísticas sobre o cache padrão. As |informações mais úteis exibidas são o quão completo é o cache e quantas classes |ele contém. Observe que as classes "stale" são classes que foram atualizadas |no sistema de arquivos e, portanto, qual cache foi marcado com "stale". As classes Stale |não são limpas do cache. Consulte o Manual de Diagnóstico para obter mais informações.|printAllStats (opção do utilitário) ||Exibe informações detalhadas sobre o conteúdo do cache especificado |na subopção name=<name>. |Se o nome não for especificado, serão exibidas as estatísticas sobre o cache padrão. Cada classe é listada na ordem cronológica juntamente com uma referência |ao local de onde ela foi carregada. Consulte o Manual de Diagnóstico para obter mais informações. | |Criando, Preenchendo, Monitorando e Excluindo um Cache |Para ativar o compartilhamento de classe, inclua -Xshareclasses[:name=] na linha de comandos do aplicativo. A VM se conectará a um cache |existente com um nome específico ou criará um novo cache com esse nome. Se |um novo cache for criado, ele será preenchido com todas as classes de |auto-inicialização e de aplicativos que estão sendo carregadas, até ficar |completamente cheio. Se dois ou mais VMs forem iniciados de forma concorrente, |todos preencherão o cache de forma concorrente.  |Para verificar se o cache foi criado, execute java |-Xshareclasses:listAllCaches .  Para ver quantas classes e quantos dados das classes estão sendo compartilhados, execute java -Xshareclasses:[name=],printStats. (Esses utilitários podem |ser executados após o término da VM do aplicativo ou em outra janela de comando) |Para ver as classes que estão sendo carregadas do cache ou armazenadas nele, inclua -Xshareclasses:[name=],verbose na linha de comandos do |aplicativo. |Para excluir o cache criado, execute java -Xshareclasses:[name=],delete.  Você terá que excluir caches somente se eles contiverem muitas classes |stale ou se o cache estiver cheio e você desejar criar um cache maior.  |Convém ajustar o tamanho do cache para o seu aplicativo específico, uma |vez que não é provável que o padrão seja o tamanho ideal. O melhor meio de |determinar o tamanho ideal do cache é especificar um cache grande (com | -Xscmx), executar o aplicativo e utilizar |printStats para determinar quantos dados de classe foram armazenados.  |Inclua um valor pequeno no valor mostrado em printStats para contingência.  |Não se esqueça de que, como as classes podem ser carregadas a qualquer |momento durante a existência da VM, é melhor que essa análise seja feita |depois da conclusão do aplicativo. Contudo, um cache cheio não causa um |efeito negativo no desempenho ou capacidade de qualquer VM conectada a |ele; assim é plenamente justificável escolher um tamanho de cache menor do |que o requerido. |Se um cache ficar cheio, uma mensagem será exibida na linha de comandos de |todas as VMs que o utilizem, e elas carregarão quaisquer classes |adicionais na própria memória de processo. As classes em um cache cheio |ainda podem ser compartilhadas, contudo ele é de somente leitura e não |pode ser atualizado com novas classes.  | |Desempenho e Consumo de Memória |O compartilhamento de classe é particularmente útil em sistemas que |utilizam mais de uma VM com código semelhante; os sistemas se beneficiam |do consumo reduzido de memória virtual. Também é útil em sistemas que |freqüentemente inicializam e encerram VMs, que se beneficiam do |aprimoramento no tempo de inicialização.  |O código extra para criar e preencher um novo cache é mínimo. O custo do |tempo de inicialização de uma única VM é, normalmente, entre 0 e 5%, |dependendo de quantas classes são carregadas. O tempo de inicialização da |VM melhorado com um cache preenchido geralmente está entre 10% e 40%, |dependendo do sistema operacional e do número de classes carregadas.  |Várias VMs executando simultaneamente exibirão benefícios de tempo de |inicialização total maiores.  |Quando você executar seu aplicativo com compartilhamento de classe, poderá utilizar as ferramentas |do sistema operacional para ver a redução no consumo de memória virtual.  | |Limitações e Considerações sobre Como Utilizar o Compartilhamento de Classe | |Limites no Tamanho do Cache |O cache para compartilhamento de classes é alocado utilizando o mecanismo |de memória System V IPC Shared.  |O tamanho do cache teórico máximo é 2 GB. o tamanho do |cache que você pode especificar está limitado pela quantidade de espaço de | paginação disponível |para o sistema.  |Como o espaço de endereço virtual de um processo é compartilhado entre o |cache de classes compartilhadas e o heap Java, aumentar o tamanho máximo |do heap Java reduzirá o tamanho do cache de classes compartilhadas que |pode ser criado.  |O tamanho do cache é limitado pelas configurações do SHMMAX, |o qual limita a quantidade de memória compartilhada que pode ser alocada. Você pode localizar |essas configurações no arquivo /proc/sys/kernel/shmmax. SHMMAX geralmente é definido como 30 MB. | |Modificação do Bytecode de Tempo de Execução |Qualquer VM que utilize um agente JVMTI que possa modificar o bytecode não pode compartilhar |classes a não ser que a subopção modified= seja utilizada na |linha de comandos (veja acima). O contexto modificado é um descritor especificado pelo usuário |que descreve o tipo de modificação que está sendo executada. Todos os VMs que utilizam um determinado |contexto modificado devem modificar o bytecode de uma maneira previsível e repetida |para cada classe, de forma que as classes modificadas armazenadas no cache tenham |as modificações esperadas quando forem carregadas por outra VM. O motivo |de qualquer modificação precisar ser previsível é que as classes |carregadas do cache de classes compartilhadas não podem ser novamente |modificadas pelo agente. Observe que o bytecode |modificado e não modificado pode ser armazenado no mesmo cache. Consulte o Manual de Diagnóstico para obter mais detalhes sobre este tópico. | |Limitações do Sistema Operacional |Para sistemas operacionais que podem executar os aplicativos de |32 bits e 64 bits, o compartilhamento de classe não é permitido entre VMs de 32 bits e 64 bits. |A subopção listAllCaches listará caches de 32 bits ou 64-bits, |dependendo do modo de endereço da VM que está sendo utilizado.  |O cache de classes compartilhadas requer espaço em disco para armazenar informações de identificação |sobre os caches existentes no sistema. Essas informações |estão armazenadas em /tmp/javasharedresources. Se o diretório de informações de |identificação for excluído, a VM não poderá identificar as classes compartilhadas no sistema |e deverá recriar o cache. Utilize o comando ipcs |para visualizar os segmentos de memória utilizados por uma VM ou aplicativo. |Os usuários que estão executando em uma JVM devem estar no mesmo grupo para utilizar |um cache de classes compartilhadas. As permissões para acessar um |cache de classes compartilhadas são forçadas pelo sistema operacional. Por padrão, se um nome de cache não for |especificado, o nome do usuário será anexado ao nome padrão para que vários |usuários no sistema operacional criem seus próprios caches. | |Utilizando SharedClassPermissions |Se um SecurityManager estiver sendo utilizado em conjunto com o |compartilhamento de classe e o aplicativo em execução utilizar seus |próprios classloaders, tais classloaders devem possuir a permissão |SharedClassPermissions antes que possam compartilhar classes. Inclua |SharedClassPermissions no arquivo java.policy utilizando o nome de classe |ClassLoader (caracteres-curinga são permitidos), e "read",   "write" ou |"read,write" para determinar o acesso concedido. |Exemplo: |permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";Se um ClassLoader sem a permissão SharedClassPermission correta tentar |compartilhar classes, a exceção AccessControlException será emitida.  Não |é possível alterar ou reduzir as permissões dos classloaders de |auto-inicialização, aplicativo ou extensão.  | |Adaptando Carregadores de Classe Personalizados às Classes de Compartilhamento |A maioria dos aplicativos Java utilizará os próprios carregadores de classe da VM ou terá |carregadores de classe personalizados que estendam java/net/URLClassLoader.  |Aplicativos que utilizem tais classloaders poderão compartilhar |automaticamente classes de auto-inicialização e de aplicativos. |Os carregadores de classe personalizados que não estendam java/net/URLClassLoader irão requerer |modificações para utilizar o compartilhamento de classes. Todos os |classloaders precisarão receber permissões SharedClassPermissions caso um |SecurityManager seja utilizado; consulte |Utilizando SharedClassPermissions. A IBM apresenta várias interfaces Java para diversos tipos de |classloaders personalizados, as quais permitem que os classloaders |localizem e armazenem classes no cache de classes compartilhadas. Essas classes estão no pacote |com.ibm.oti.shared. O Javadoc desse pacote é fornecido com o SDK no |arquivo docs/apidoc.zip. Consulte o Manual de |Diagnóstico para obter mais informações sobre como utilizar essas interfaces.  Serviço e Suporte para Fornecedores Independentes de Software  Se você estiver qualificado para os serviços do código do Programa relativos ao programa IBM Solutions Developer, entre em contato com esse Programa por meio de seu método normal de acesso ou pela Web em: http://www-1.ibm.com/partnerworld/. Se você adquiriu um contrato de serviço (isto é, Linha de Suporte aos Sistemas Pessoais da IBM ou serviço equivalente por país), os termos e condições desse contrato de serviço determinam quais serviços, se existirem, você está qualificado a receber com relação ao Programa.   Acessibilidade Os Guias do Usuário fornecidos com este SDK e o Runtime Environment foram testados utilizando os leitores de tela. É possível utilizar um leitor de tela como o Home Page Reader ou o leitor de tela JAWS com esses Guias do Usuário.  Para alterar os tamanhos de fonte nos Guias do Usuário, utilize a função fornecida com seu navegador, normalmente encontrada na opção de menu Exibir. Para usuários que necessitam da navegação via teclado, há uma descrição do pressionamento de teclas úteis dos aplicativos Swing em "Swing Key Bindings", no site http://www-128.ibm.com/developerworks/java/jdk/additional/  Acessibilidade iKeyman |Em adição à GUI, a ferramenta iKeyman apresenta a ferramenta de linha de |comandos IKEYCMD com as mesmas funções que a |interface gráfica com o usuário (GUI) do iKeyman. O IKEYCMD permite que você gerencie teclas, |certificados e pedidos de certificados. Você pode chamar o IKEYCMD a partir de scripts shell nativos e de programas que deverão ser utilizados quando |os aplicativos precisarem incluir interfaces personalizadas nas tarefas de gerenciamento de certificados |e chaves. O IKEYCMD pode criar arquivos do banco de dados de chaves para todos |os tipos que o iKeyman suporta atualmente. O IKEYCMD pode |também criar pedidos de certificados, importar certificados assinados CA e gerenciar |certificados auto-assinados.  Para executar um comando IKEYCMD, digite: java [-Dikeycmd.properties=]com.ibm.gsk.ikeyman.ikeycmd  [options]em que:  é uma das seguintes opções: -keydbAções tomadas no banco de dados de chaves (um arquivo do banco de dados de chaves CMS, um arquivo de chaves WebDB ou uma classe SSLight) -certAções a serem tomadas num certificado dentro de um banco de dados de chaves -certreqAções a serem tomadas num pedido de certificado dentro de um banco de dados de chaves -versionExibe informações sobre versão do IKEYCMD -helpExibe ajuda para as chamadas do IKEYCMD.  |A ação específica a ser tomada no objeto. Para consultar as ações |disponíveis para um objeto, chame IKEYCMD e informe |apenas o objeto como argumento. A ajuda sensível a contexto será exibida |mostrando as ações disponíveis para esse objeto.  -Dikeycmd.propertiesEspecifica o nome de um arquivo de propriedades opcional para utilizar com essa invocação Java. Um arquivo de propriedades padrão, ikeycmd.properties, é fornecido como um arquivo de amostra que pode ser alterado e utilizado por qualquer aplicativo Java.   Nota: As palavras-chave object e action devem estar na seqüência especificada. Contudo, as opções não são posicionais e podem estar em qualquer seqüência, desde que estejam especificadas como um par de opção e operando. Para obter mais informações, consulte o Guia do Usuário do iKeyman em: http://www.ibm.com/developerworks/java/jdk/security/index.html.  Keyboard Traversal dos Componentes JComboBox no Swing Se você percorrer a lista drop-down de um componente JComboBox com as teclas do cursor, o botão ou o campo editável da caixa de combinação não alterará o valor até que um item seja selecionado. Esse é o comportamento ideal para este release e melhora a acessibilidade e a utilidade assegurando que o comportamento do keyboard traversal seja consistente com o comportamento do mouse traversal.  Acessibilidade do Web Start (Somente Linux IA 32-bit, PPC32 e PPC64)  O IBM Java Web Start v5.0 contém vários aprimoramentos de acessibilidade e usabilidade a mais que o release anterior, incluindo melhor suporte para leitores de tela e navegação do teclado aprimorada. Você pode usar apenas a linha de comandos para ativar um aplicativo Java que seja ativado para o Web Start.  Para alterar as opções de preferência, você deverá editar um arquivo de configuração, .java/.deployment/.deployment.properties no diretório home do usuário. Faça um backup antes de editar esse arquivo.  Nem todas as preferências que podem ser definidas no Java Application Cache Viewer estão disponíveis no arquivo de configuração.   Limitações Conhecidas As seções a seguir explicam as limitações conhecidas do SDK e do Runtime Environment para Linux.  Limitações que se Aplicam a Todas as Plataformas Linux, Exceto Onde Indicado |O gerenciador de janelas pode substituir alguns atalhos do teclado Java. Se precisar utilizar um atalho do teclado Java, consulte |o manual do sistema operacional e altere os atalhos do teclado do gerenciador de janelas. ||O Sistema Windows X não pode utilizar os descritores de arquivo posteriores ao 255. Como a JVM contém descritores de arquivos para os arquivos jar abertos, o X pode ser executado fora dos descritores de arquivos. Como uma solução alternativa, você pode definir a variável de ambiente  JAVA_HIGH_ZIPFDS para que a JVM utilize descritores de arquivos mais recentes para arquivos jar. |Para utilizar a variável de ambiente JAVA_HIGH_ZIPFDS, defina-a como um valor entre 0 e 512. A JVM, então, abrirá os primeiros arquivos jar utilizando descritores de arquivo até 1024. Por exemplo, |se o programa conseguir carregar 300 arquivos jar:export JAVA_HIGH_ZIPFDS=300 |Os primeiros 300 arquivos jar, então, serão carregados utilizando descritores de arquivo 724 a 1023. Os arquivos jar abertos após isso serão abertos no intervalo normal.É possível que você não consiga utilizar a área de transferência do sistema com DBCS (Conjunto de Caracteres de Byte Duplo) para copiar informações entre aplicativos Linux e Java, caso esteja executando o KDE (K Desktop Environment). No RHEL3, no SLES9 e em distribuições mais recentes, a biblioteca de encadeamentos padrão é NPTL, que implementa os encadeamentos Java como encadeamentos nativos. Em distribuições anteriores, a biblioteca de encadeamentos padrão é LinuxThreads, que implementa os encadeamentos como novos processos. Se o número de encadeamentos Java exceder o número máximo de processos permitidos, seu programa pode ser interrompido.  O número máximo de encadeamentos disponíveis é determinado pelo menor valor de: A definição dos processos de usuário (ulimit -u) em /etc/security/limits.confO limite definido em /proc/sys/kernel/threads_maxO limite PTHREAD_THREADS_MAX definido no libpthreads.so (a alteração desse valor requer a recompilação de glibc). Entretanto, você poderá ficar sem armazenamento virtual antes de atingir o número máximo de encadeamentos.Se você encerrou um aplicativo Java com um Ctrl-C, vários processos poderão ser deixados órfãos. Os resultados de KeyEvent que incluem a tecla ALT diferem ao utilizar diferentes gerenciadores de janelas no Linux. Além disso, diferem dos resultados de outros sistemas operacionais. No gerenciador de janelas Enlightenment, Alt+A e Shift+Alt+A produzem modificadores diferentes e Ctrl+Alt+A não produz eventos de tecla. No entanto, ao utilizar o gerenciador de janela WindowMakerr, Ctrl+Alt+A irá produzir um evento de tecla. No Sistema Linux X Window, o mapa de teclas está definido para: 64 0xffe9 (Alt_L) 0xffe7 (Meta_L) e 113 0xffea (Alt_R) 0xffe8 (Meta_R).  Para verificar isto, digite este comando em um prompt do shell:  xmodmap -pk  Esse é o motivo pelo qual o SDK considera que Meta + Alt estão sendo processados juntos. Como alternativa, é possível remover o mapeamento de Meta_x, digitando o seguinte em um prompt do shell: xmodmap -e "keysym Alt_L = Alt_L" -e "keysym Alt_R = Alt_R"   Nota: Essa alternativa poderá afetar outros aplicativos X-Window que estão sendo executados na mesma tela caso eles utilizem a tecla Meta removida. A criação de pares de chaves DSA de comprimentos incomuns pode demorar um tempo significativo em máquinas mais lentas. Não interprete esse atraso como uma interrupção porque o processo será concluído se for permitido tempo suficiente. O algoritmo de geração da chave DSA foi otimizado para gerar comprimentos de chave padrão (neste caso, 512, 1024) com mais rapidez que os outros.   Programas nativos não podem criar uma VM com interfaces JNI_VERSION_1_1(0x00010001). Não é possível chamar JNI_CreateJavaVM() e transmitir uma versão de JNI_VERSION_1_1(0x00010001). As versões que podem ser aprovadas são: JNI_VERSION_1_2(0x00010002)JNI_VERSION_1_4(0x00010004) A VM criada é determinada pelas bibliotecas Java presentes (ou seja, 1.2.2, 1.3.x, 1.4.x, 5.x), e não aquela deduzida pela versão da interface JNI transmitida. A versão da interface não afeta nenhuma área do comportamento da VM, exceto as funções disponíveis para o código nativo.Uma chamada para JNI_CreateJavaVM() a partir de um aplicativo JNI pode gerar uma falha de segmentação (sinal SIGSEGV); para evitar essa falha, reconstrua o programa JNI especificando a opção -lpthread. Somente para usuários do chinês tradicional, as teclas de função Enter, Space, Backspace e ESC não funcionam da maneira esperada ao utilizar os IMEs LinYi ZhuYin, YiTian ZhuYin e Bosham para inserir os caracteres TCH. A tecla Enter insere uma nova linha, a tecla ESC é utilizada para cancelar as cadeias de pré-edição ou a janela candidata e barra de espaço insere um espaço. A janela candidata deve desaparecer após a tecla de consolidação ter sido pressionada e não deve aparecer quando você pressionar a tecla backspace enquanto utiliza os IMEs LinYi ZhuYin, YiTian ZhuYin e Bosham para inserir os caracteres de chinês tradicional.  Se você estiver trabalhando com vários encadeamentos simultâneos, poderá obter uma mensagem de aviso: java.lang.OutOfMemoryError. Isso é uma indicação de que sua máquina está sendo executada sem recursos de sistema e as mensagens podem ser causadas pelas seguintes razões:  Novos encadeamentos não podem ser criados porque:  O número de processos criados ultrapassa o limite do usuário. (Se a instalação Linux utilizar LinuxThreads, em vez de NPTL.)Não há recursos de sistema suficientes que estejam disponíveis para criar novos encadeamentos. Nesse caso, talvez seja necessário consultar também outras exceções Java, dependendo de qual aplicativo está sendo executado.  O kernel está sem memória ou está fragmentado. Poderão ser vistas mensagens correspondentes de Sem Memória do kernel no /var/log/messages que possui o ID do processo eliminado. Tente ajustar o sistema para aumentar seus recursos correspondentes. Durante a instalação, se a versão anterior deste produto, distribuída pela Red Hat, já tiver sido instalada, o RPM (Red Hat Package Manager) relatará que o pacote IBM é mais antigo que quaisquer versões do produto que a Red Hat distribuiu. Essa condição ocorre porque o Red Hat adiciona ao pacote RPM um "número de série" que substitui o esquema de versões do produto no pacote e, por padrão, o RPM se recusa a instalar um pacote que pareça ser mais antigo que o já instalado. A opção --oldpackage do comando rpm permite a instalação do novo pacote IBM.  Ao executar um aplicativo Java AWT/Swing em uma máquina Linux e exportar a exibição para uma segunda máquina, poderão ocorrer problemas ao exibir alguns diálogos se o conjunto de fontes carregadas na máquina cliente X for diferente do conjunto carregado na máquina servidor X. Esse problema é visível particularmente com SLES8 em localidades do idioma chinês, em que a instalação padrão da versão do servidor instala as fontes arphic, mas a instalação padrão do cliente não o faz. Para evitar esse problema, instale as mesmas fontes em ambas as máquinas.  Se a localidade do seu sistema estiver utilizando a codificação UTF-8, algumas ferramentas do SDK podem apresentar uma sun.io.MalformedInputException. Para descobrir se seu sistema está utilizando uma codificação UTF-8, analise as variáveis de ambiente específicas da localidade como LANG ou LC_ALL para ver se elas terminam com o sufixo ".UTF-8". Se você encontrar uma sun.io.MalformedInputException, altere os caracteres que não estão dentro da série de 7-bit ASCII (0x00 - 0x7f) e que não são representados como caracteres literais de Java Unicode para caracteres literais de Java Unicode (por exemplo: '\u0080'). Você pode também obter uma solução alternativa para este problema removendo o sufixo ".UTF-8" das variáveis de ambiente específicas da localidade; por exemplo, se sua máquina tiver a localidade padrão de "en_US.UTF-8", defina LANG para "en_US".  Nota: Algumas distribuições do Red Hat, incluindo Red Hat 9 e RHEL3, utilizam por padrão a codificação UTF-8. Se você estiver utilizando AMI e xcin em um ambiente de plataforma cruzada (por exemplo, se você tentar exportar a exibição entre um sistema de 32-bit e um de 64-bit ou entre um sistema big-endian e um little-endian) podem ocorrer alguns problemas. Se você tiver esse tipo de problema, entre em contato com um distribuidor Linux. No Red Hat Enterprise Linux 3, os caracteres chineses podem não ser exibidos nos componentes de texto AWT, exceto caracteres GB2312 no código do idioma chinês GB18030.  |Na ferramenta JConsole da IBM, a guia Local, que permite |conectar-se a outras JVMs no mesmo sistema, não está disponível. Em vez dessa guia, utilize Remoto no JConsole |para conectar-se à JVM que você deseja monitorar. Ao ativar o aplicativo que você deseja |monitorar, defina estas opções na linha de comandos: ||-Dcom.sun.management.jmxremote.port= para especificar a porta que o agente de gerenciamento deve verificar. |-Dcom.sun.management.jmxremote.authenticate=false para desativar a autenticação, a menos que você tenha criado um arquivo de nome do usuário. |-Dcom.sun.management.jmxremote.ssl=false para desativar a criptografia SSL. ||No caso de usuários dos idiomas chinês, coreano e japonês do Red Hat |Enterprise Linux 4 apenas, se você estiver utilizando o Internet/Intranet Input Method |Framework (IIIMF), utilize pacotes IIIMF incluídos no Red Hat Enterprise |Linux 4 Update 2 ou mais recente. Além disso, observe o seguinte problema. Se ocorrer esse problema, entre em contato com o Red Hat para obter orientação, no site http://www.redhat.com. ||No Linux zSeries de 64 bits, podem ocorrer defeitos no IIIMF ou um defeito ao iniciar. Consulte o Red Hat Bugzilla, número RIT73533, para usuários japoneses apenas. ||Para usuários do idioma chinês simplificado do Red Hat Enterprise |Linux 4 apenas. O código do idioma zh_CN.GB18030 não é suportado por xlib no RHEL4. |xterm não pode ativar o método de entrada para a entrada de caracteres GB18030. Utilize o código do idioma zh_CN.UTF8. Se você tiver programas herdados ou dados codificados com GB2312, GBK ou GB18030, e desejar migrá-los para o RHEL4, pré-processe-os com iconv para convertê-los em codificação utf-8 para que os programas possam ser executados e os dados possam ser exibidos corretamente no RHEL4 com o código do idioma zh_CN.UTF8. ||No RHEL 3 com miniChinput (servidor XIM em chinês simplificado) em ambientes de 64 bits (como plataformas AMD64 ou zSeries de 64 bits), o Java pode apresentar um comportamento inesperado. Entre em contato com o Red Hat para obter orientação, no site http://www.redhat.com. Consulte o Red Hat Bugzilla, número RIT75701. ||No RHEL 3 com ami (servidor XIM em coreano), o Java em ambientes de 64 bits pode apresentar um comportamento inesperado (como plataformas AMD64 ou zSeries de 64 bits). Entre em contato com o Red Hat para obter orientação, no site http://www.redhat.com. Consulte o Red Hat Bugzilla, números RIT73605 e RIT75708. ||No RHEL 4 com xcin (servidor XIM em chinês tradicional), o Java em ambientes de 64 bits pode apresentar um comportamento inesperado, como falha de segmentação (como plataformas AMD64 ou zSeries de 64 bits). Entre em contato com o Red Hat para obter orientação, no site http://www.redhat.com. |Consulte o Red Hat Bugzilla, número RIT78430. ||No caso de usuários dos idiomas japonês, chinês e coreano, não é possível utilizar XIM para entrar seus próprios caracteres nos componentes de texto de um applet Java em um navegador da Web. |Essa limitação ocorre porque o XEmbed requer uma correção no arquivo da biblioteca X11. |Para evitar isso, especifique o parâmetro do sistema -Dsun.awt.noxembed=true para desativar o XEmbed. Você pode utilizar o painel de controle para definir essa opção: ||Abra o Java Plug-in Control Panel e acesse a guia Java. |Clique no botão Visualizar nas Configurações do Java Applet Runtime. |Entre -Dsun.awt.noxembed=true nos Parâmetros do Java Runtime e clique em OK. |Clique em Aplicar |Inicie um navegador. |  Limitações do Linux IA 32-bit Para usuários de texto em árabe, ao utilizar o Linux com uma placa de vídeo Matrox e aceleração ativada, a distorção de caracteres pode ser vista ao utilizar drawString para exibir as fontes grandes. Esse problema é causado pelo driver dessas placas. A solução alternativa é desativar a aceleração do dispositivo. No SLES 9 NPTL, o driver de porta paralela causa um travamento de kernel e oculta um encadeamento Java. A JVM detecta esse travamento quando tenta suspender o encadeamento da Coleta de Lixo e, em seguida, trava ao produzir um arquivo de núcleo e a mensagem "JVMLH030: encadeamentos estão desaparecendo ao tentar suspender todos os encadeamentos". O relatório 47947 do SUSE Bugzilla é emitido para esse problema. Esse erro é corrigido no SLES 9 Service Pack 1.  Limitações do Linux AMD64 | |Nota importante sobre as configurações BIOS nos sistemas AMD64 SMP: |A configuração BIOS Intercalação de memória do nó deve |ser definida como DESATIVADA. Caso contrário, poderão ocorrer resultados inesperados, |incluindo travamentos e interrupções do Java. Essa instrução está de acordo com a recomendação |do AMD.  Limitações do Linux PPC 32-bit e 64-bit Se o seu código Java utiliza chamadas da JNI e alguma chamada específica tiver mais de oito parâmetros float ou double, seu código C deve ser compilado com o nível gcc-2.95.3 FSF (Free Software Foundation) do GCC (GNU C Compiler).  Se você estiver executando a versão 3.x do XFree86, você pode receber um erro SIGSEGV. Para evitar esse problema, é recomendado que você utilize a versão 4.x do XFree86. Se a data estiver definida para uma data anterior a 1970, você irá obter um erro de exceção quando tentar iniciar o Java. Para solucionar este problema, defina manualmente a data de sua máquina para a data atual. O pacote JavaComm não pode suportar operações de porta paralela nos kernels do SLES 9 GA e do SP1. Essa limitação é resolvida no kernel do SP2. O número do SUSE Bugzilla é 50028. Devido a uma função IOCTL não implementada no modo de 32 bits do kernel de 64 bits, o JavaComm não pode suportar operações de porta no SLES 9 e no RHEL 4. Essa limitação foi resolvida no SLES 9 SP2 (Bugzilla número 49787) e RHEL 4 atualização 1 (Bugzilla número 144904).   Limitações do Linux PPC 64-bit O compilador cruzado gcc padrão (versão 3.2-49) causa vários erros. Para gerar a biblioteca compartilhada libFileStat.so, execute /opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I/include FileStat.c em que  é o caminho para o diretório do SDK instalado.   Limitações do Linux zSeries 64-bit As seguintes limitações aplicam-se aos usuários chineses e taiwaneses no Linux zSeries de 64 bits: O servidor do método de entrada de chinês e taiwanês (xcin) não foi testado com a Versão 5.0.   Limitações do Linux zSeries de 31 bits e de 64 bits Se você utilizar o áudio em uma máquina sem uma placa de som, poderá aparecer uma mensagem de erro indicando que não há memória suficiente quando o Java tentar reproduzir o som. A mensagem será exibida no console mas ela não irá afetar seu aplicativo Java.  Embora o kernel do Linux nas distribuições atuais forneça suporte ao IP6 (Internet Protocol Versão 6), é possível encontrar problemas ao utilizá-lo. O suporte ao IP6 do Java está incluso neste release, mas é aconselhável que este seja desligado com a opção -Djava.net.preferIPv4Stack=true no comando Java. Se um kernel for instalado e o mesmo suportar completamente o IP6, não será necessária esta opção. |Se você estiver utilizando o Java for zSeries de 31 bits ou de 64 bits com o servidor X utilizando uma configuração de alta resolução, os glifos de fonte do componente AWT Choice com Motif AWT poderão ficar recortados. Para evitar isso, diminua a configuração da resolução ou utilize XAWT em vez de Motif AWT. |  Algum Comentário Sobre este Guia do Usuário? Caso tenha algum comentário sobre a utilidade, ou não, deste Guia do Usuário, gostaríamos de saber sua opinião através do correio. Observe que esse meio não foi implementado para responder perguntas técnicas - esse meio é apenas para comentários sobre a documentação. Envie seus comentários: Por e-mail: idrcf@hursley.ibm.com.Por fax:  Do Reino Unido: 01962 842327 De outros locais:44 1962 842327  Por escrito para:  Centro de Tecnologia IBM - Centro de TraduçõesRodovia SP 101 km 09CEP 13185-900Hortolândia, SP Observações. Ao mandar uma mensagem para a IBM, o Cliente concorda que todas as informações contidas em sua mensagem, incluindo dados sobre feedback, como perguntas, comentários, sugestões ou informações similares, serão classificadas como não-confidenciais; a IBM não possui nenhuma obrigação de qualquer tipo em relação a tais informações e poderá reproduzir, utilizar, divulgar e distribuir as informações a terceiros sem nenhuma limitação. A IBM poderá usar todas as idéias, conceitos, conhecimentos ou técnicas contidas em tais informações para o fim que desejar, incluindo, mas não se limitando a desenvolvimento, fabricação e marketing de produtos incorporando tais informações.  Avisos  Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos. A IBM pode não oferecer os produtos, serviços ou recursos discutidos neste documento em outros países. Consulte seu representante da IBM local para obter informações sobre os produtos e serviços atualmente disponíveis em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM ou quaisquer outros direitos da IBM, poderá ser utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não-IBM é de inteira responsabilidade do Cliente. A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para: Gerência de Relações Comerciais e Industriais da IBM BrasilAv. Pasteur, 138-146BotafogoRio de Janeiro, RJCEP 22290-240 Para pedidos de licenças com relação a informações sobre DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos, por escrito, para: IBM World Trade Asia Corporation Licensing2-31 Roppongi 3-chome, Minato-kuTokyo 106-0032, Japan O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS DE MERCADO OU DE ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ou implícitas em certas transações; portanto, esta disposição pode não se aplicar ao Cliente. Estas informações podem incluir imprecisões técnicas ou erros tipográficos. Periodicamente, são feitas alterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode fazer aperfeiçoamentos e/ou alterações nos produtos e/ou programas descritos nesta publicação, a qualquer momento e sem aviso prévio. Referências nestas informações a Web sites não-IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a esses Web sites. Os materiais contidos nesses Web sites não fazem parte dos materiais deste produto IBM e a utilização desses Web sites é de responsabilidade do usuário. A IBM pode utilizar ou distribuir qualquer informação fornecida, da forma que julgar apropriada, sem que isso incorra em qualquer obrigação para com o Cliente. Licenciados deste programa que pretendam obter mais informações sobre o mesmo com o objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com: Gerência de Relações Comerciais e Industriais da IBM BrasilAv. Pasteur, 138-146BotafogoRio de Janeiro-RJCEP 22290-240 Tais informações podem estar disponíveis, sujeitas a termos e condições apropriados, incluindo, em alguns casos, o pagamento de uma taxa. O programa licenciado descrito neste documento e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com Cliente IBM, Contrato de Licença de Programa Internacional IBM ou qualquer contrato equivalente.  Todos os dados de desempenho aqui descritos foram determinados em um ambiente controlado. Portanto, os resultados obtidos em outros ambientes operacionais podem variar significativamente. Algumas medidas podem ter sido tomadas em sistemas em fase de desenvolvimento e não há garantia de que tais medidas sejam as mesmas nos sistemas normalmente disponíveis. Além disso, algumas medições podem ter sido estimadas através de extrapolação. Os resultados reais podem variar. Os usuários deste documento devem verificar os dados que se aplicam ao seu ambiente específico. As informações referentes a produtos não-IBM foram obtidas junto a fornecedores desses produtos, anúncios publicados ou outras fontes publicamente disponíveis. A IBM não testou esses produtos e não pode confirmar a precisão de desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos não-IBM. Dúvidas sobre os recursos dos produtos não-IBM devem ser encaminhadas aos fornecedores dos respectivos produtos.    Marcas Registradas IBM, iSeries, pSeries e zSeries são marcas ou marcas registradas da International Business Machines Corporation nos Estados Unidos e/ou em outros países. Intel é uma marca registrada da Intel Corporation nos Estados Unidos e/ou em outros países. Java e todas as marcas registradas e logotipos baseados em Java são marcas ou marcas registradas da Sun Microsystems, Inc., nos Estados Unidos e/ou em outros países.  Linux uma marca registrada da Linus Torvalds nos Estados Unidos e/ou em outros países. Outros nomes de empresas, produtos ou serviços podem ser marcas registradas ou marcas de serviço de terceiros. Este produto também é baseado em parte do trabalho do Projeto FreeType. Para obter mais informações sobre o Freetype, consulte http://www.freetype.org. Este produto inclui software desenvolvido pela Apache Software Foundation  http://www.apache.org/.Fonte: http://www.ibm.com/developerworks/eserver/library/es-JavaVirtualMachinePerformance.html