IBM SDK para Plataformas Linux, Java Technology Edition, Versão 6

Guia de SDK e Runtime

Versão 6 Release 0

Copyright International Business Machines Corporation 2003, 2007. Todos os direitos reservados.

Índice

Prefácio
Visão Geral
Convenções
Compatibilidade entre Versões
Migrando de outras IBM JVMs
Hardware Suportado para System z
Conteúdo do SDK e Runtime Environment
Classes e Ferramentas do Runtime Environment
Ferramentas SDK e Informações de Referência
Instalando e Configurando o SDK e o Runtime Environment
Fazendo Upgrade do SDK
Instalando no RHEL (Red Hat Enterprise Linux) 4
Instalando no RHEL (Red Hat Enterprise Linux) 5
Executando o Java com SELinux no RHEL 5
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
Utilizando um Formato Compatível de JPackage
Configurando o SDK e o Runtime Environment para Linux
Configurando o Caminho
Configurando o Caminho de Classe
Desinstalando o SDK e o Runtime Environment para Linux
Desinstalando o Pacote RPM (Red Hat Package Manager)
Desinstalando o Pacote TAR (Tape Archive) Compactado
Executando Aplicativos Java
Comandos java e javaw
Obtendo Informações de Versão
Especificando Opções Java e Propriedades de Sistema
Opções Padrão
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
Suporte ao Símbolo Euro
Arquivos de Configuração de Fonte Predefinida
| |
Utilizando os Métodos de Entrada Indiano e Tailandês
Utilizando o SDK para Desenvolver Aplicativos Java
| |
Utilizando o XML
| |
Migrando para o XL-TXE-J
| |
Informações de Referência de XML
Depurando Aplicativos Java
JDB (Java Debugger)
Determinando se o Aplicativo Está Sendo Executado em uma JVM de 32 bits ou de 64 bits
Como a JVM Processa Sinais
Sinais Utilizados pela JVM
Vinculando um Driver de Código Nativo à Biblioteca de Cadeia de Sinais
Escrevendo Aplicativos JNI
Suporte para Recuperação de Conectores Bloqueados em Nível de Encadeamento
Configurando a Alocação da Memória de Página Grande
Suporte ao CORBA
Propriedades do Sistema para Rastrear o ORB
Propriedades do Sistema para Ajustar o ORB
Permissões de Segurança do Java para o ORB
Classes de Implementação do ORB
RMI sobre IIOP
Implementando o Conjunto de Rotinas de Tratamento de Conexão para RMI
BigDecimal Avançado
Plug-in, Applet Viewer e Web Start
(Somente Linux IA 32-bit e PPC32) Utilizando o Plug-in Java
Navegadores Suportados
Instalando e Configurando o Plug-in Java
Suporte a DOM (Document Object Model)
Utilizando Parâmetros DBCS
Trabalhando com Applets
Executando Applets com o Applet Viewer
Depurando Applets com o Applet Viewer
(Somente Linux IA 32-bit, PPC32 e PPC64) Utilizando o Web Start
Executando o Web Start
(Somente Linux IA 32-bit) Desenvolvimento de Versões Estático Seguro do Web Start
Remessa de Aplicativos Java
Compartilhamento de Dados de Classe Entre JVMs
Visão Geral do Compartilhamento de Dados de Classe
Ativando e Configurando o Compartilhamento de Dados de Classe
Criando, Preenchendo, Monitorando e Excluindo um Cache
Desempenho e Consumo de Memória
Considerações e Limitações sobre a Utilização do Compartilhamento de Dados de Classe
Limites no Tamanho do Cache
Modificação do Bytecode de Tempo de Execução
Limitações do Sistema Operacional
Utilizando SharedClassPermission
Adaptando Carregadores de Classe Personalizados às Classes de Compartilhamento
Utilizando o JavaComm (Java Communications) API
Instalando a API Java Communications a partir de um Arquivo Compactado
Instalando a API Java Communications a Partir de um Arquivo RPM
Local dos Arquivos da API Java Communications
Alterando o Modo de Acesso das Portas Seriais e Paralelas
Especificando Dispositivos no Arquivo javax.comm.properties
Ativando Portas Seriais no IBM ThinkPads
Limitação de Impressão com a API Java Communications
Desinstalando a API Java Communications
Desinstalando o Pacote RPM (Red Hat Package Manager)
Desinstalando o Pacote TAR (Tape Archive) Compactado
Documentação da API Java Communications
Serviço e Suporte para Fornecedores Independentes de Software
Acessibilidade
Keyboard Traversal dos Componentes JComboBox no Swing
Acessibilidade do Web Start (Somente Linux IA 32-bit, PPC32 e PPC64)
Algum Comentário sobre este Guia do Usuário?
Apêndice A. Opções Não Padrão
Apêndice B. Limitações Conhecidas
Avisos
Marcas Comerciais

Prefácio

Esse guia do usuário fornece informações gerais sobre o IBM SDK e Runtime Environment para plataformas Linux, Java Technology Edition, Versão 6 e informações específicas sobre as diferenças na implementação da IBM em comparação com a implementação da Sun.

Leia esse 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.

(Apenas plataformas Intel de 32 bits) Esses Ambientes Virtuais são suportados:

O Manual de Diagnóstico fornece informações mais detalhadas sobre o IBM Virtual Machine para Java.

Esse guia do usuário é parte de um release e é aplicável apenas a esse release específico. Certifique-se de ter em mãos o guia do usuário apropriado ao release que você está utilizando.

Os termos "Runtime Environment" e "Java Virtual Machine" são utilizados intercambiavelmente nesse guia do usuário.

|As alterações técnicas feitas para esta |versão do guia do usuário, com exceção das alterações menores ou |óbvias, são indicadas por divisas azuis ao visualizar em um Centro de |Informações, em vermelho com barras verticais à esquerda das |alterações ao visualizar em HTML ou em uma cópia impressa em cores ou |por barras verticais à esquerda das alterações ao visualizar como um |PDF.

O Código do Programa não se destina nem foi projetado para o uso em aplicativos em tempo real, como (sem limitação) o controle on-line de aeronaves, tráfego aéreo, navegação ou comunicações de aeronaves; nem para o uso em projeto, construção, operação ou manutenção de qualquer instalação nuclear.

Visão Geral

O IBM SDK é um ambiente de desenvolvimento para gravação e execução de applets e aplicativos compatíveis com o Java 6 Core API (Application Program Interface).

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 a Java Virtual Machine e os arquivos de suporte, incluindo arquivos .so não depuráveis e arquivos de classe. O Runtime Environment contém apenas um subconjunto das classes localizadas no SDK e permite suportar um programa Java no tempo de execução, mas não fornece a compilação de programas Java. O Runtime Environment para Linux não inclui qualquer das ferramentas de desenvolvimento, por exemplo, appletviewer ou o compilador Java (javac), ou classes destinadas apenas aos sistemas de desenvolvimento.

Além disso, para as plataformas IA32, PPC32/PPC64 e AMD64/EM64T, o pacote da API (Interface de Programação de Aplicativos) Java Communications é fornecido para utilização com o Runtime Environment para Linux. Informações sobre ele podem ser encontradas em Utilizando o JavaComm (Java Communications) API.

O arquivo license_xx.html contém o contrato de licença para o software Runtime Environment para Linux, em que xx é uma abreviação para o 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/java-i386-60/. Se você não estiver utilizando o Linux IA 32-bit, o diretório de instalação padrão será diferente.

As plataformas aqui listadas possuem diferentes diretórios de instalação padrão; substitua o diretório para a plataforma que estiver utilizando quando você vir /opt/ibm/java-i386-60/:

Comandos shell Korn são utilizados em exemplos em todo este guia do usuário.

Compatibilidade entre Versões

De modo geral, qualquer applet ou aplicativo que seja executado com uma versão anterior do SDK deve ser executado corretamente com o IBM SDK para Linux, v6. Não há garantia de que as classes compiladas com este release funcionem com os releases anteriores.

Para obter informações sobre problemas de compatibilidade entre releases, consulte o Web site da Sun em:

|http://java.sun.com/javase/6/webnotes/compatibility.html

http://java.sun.com/j2se/5.0/compatibility.html

http://java.sun.com/j2se/1.4/compatibility.html

http://java.sun.com/j2se/1.3/compatibility.html

Se você estiver utilizando o SDK como parte de um outro produto (por exemplo, o IBM WebSphere Application Server) e fizer upgrade de um nível anterior do SDK, talvez as classes serializadas v5.0 não sejam compatíveis. Entretanto, as classes serão compatíveis entre as atualizações de serviço.

Migrando de outras IBM JVMs

A partir da Versão 5.0, o IBM Runtime Environment para Linux contém novas versões do IBM Virtual Machine para Java e o compilador JIT (Just-In-Time).

Se você estiver migrando de um IBM Runtime Environment mais antigo, observe que:

Hardware Suportado para System z

Os SDKs and Runtime Environments System z de 31 bits e 64 bits são executados no hardware System z9 e zSeries.

Os SDKs e o Runtime Environments são executados nos seguintes servidores ou equivalentes:

Conteúdo do SDK e Runtime Environment

O SDK contém diversas ferramentas de desenvolvimento e um JRE (Java Runtime Environment). Esta seção descreve o conteúdo das ferramentas do SDK e o Runtime Environment.

Aplicativos totalmente escritos em Java não devem ter dependências na estrutura de diretórios do IBM SDK (ou nos arquivos desses diretórios). Qualquer dependência na estrutura de diretórios do SDK (ou nos arquivos desses diretórios) poderia resultar em problemas de portabilidade do aplicativo. Os aplicativos da JNI (

Os guias do usuário, Javadoc e a licença,os arquivos de copyright, javadoc, e diretório demo que os acompanham são a única documentação incluída neste SDK para Linux. É possível visualizar a documentação do software da Sun ou fazer download do pacote de documentos de software da Sun visitando o Web site da Sun: http://java.sun.com.

Classes e Ferramentas do Runtime Environment

Uma lista de classes e ferramentas que podem ser utilizadas com o Runtime Environment padrão.

Ferramentas SDK e Informações de Referência

Uma lista de ferramentas e informações de referência incluída com o SDK padrão.

As ferramentas a seguir fazem parte do SDK e estão localizadas no diretório /opt/ibm/java-i386-60/bin:
appletviewer (Java Applet Viewer)
Testa e executa applets fora de um navegador da Web.
apt (Annotation Processing Tool)
Localiza e executa processadores de anotação com base nas anotações presentes no conjunto de arquivos de origem especificados que estejam sendo examinados.
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.
(Somente Linux IA de 32 bits, PPC32 e PPC64)HtmlConverter (Java Plug-in HTML Converter)
Converte uma página HTML que contenha applets para um formato que possa utilizar o Java Plug-in.
idlj (IDL para o Java Compiler)
Gera ligações Java a partir de um determinado arquivo IDL.
ikeycmd (utilitário de linha de comandos iKeyman)
Permite gerenciar chaves, certificados e pedidos de certificado a partir da linha de comandos. Para obter mais informações, consulte o Security Guide acompanhante e http://www.ibm.com/developerworks/java/jdk/security.
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.
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.
javac (Java Compiler)
Compila programas escritos na linguagem de programação Java em bytecodes (código Java compilado).
javadoc (Java Documentation Generator)
Gera páginas HTML da documentação de API dos 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.
javap (Class File Disassembler)
Desmonta os arquivos compilados e pode imprimir uma representação dos bytecodes.
javaw (Java Interpreter)
Executa classes Java da mesma maneira que o comando java, mas não utiliza uma janela do console.
(Somente Linux IA de 32 bits, PPC32 e PPC64)javaws (Java Web Start)
Ativa a implementação e a manutenção automática dos aplicativos Java.Para obter informações adicionais, consulte Executando o Web Start.
jconsole (Ferramenta de Monitoramento e Gerenciamento JConsole)
Monitora JVMs locais e remotas utilizando uma GUI. Em conformidade com JMX.
jdb (Java Debugger)
Ajuda a depurar seus programas Java.
jdmpview (Formatador dump entre plataformas)
Analisa dumps. Para obter mais informações, consulte Manual de Diagnóstico.
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 (Java Remote Method Invocation (RMI) Stub Converter)
Gera stubs, estruturas e conexões para objetos remotos. Inclui o suporte RMI sobre Internet Inter-ORB Protocol (RMI-IIOP).
schemagen
Cria um arquivo esquema para cada espaço de nomes referenciado nas classes Java.
serialver (Comando da Versão Serial)
Retorna o serialVersionUID para uma ou mais classes em um formato adequado para copiar em uma classe envolvida.
wsgen
Gera artefatos portáveis JAX-WS utilizados em serviços da Web JAX-WS.
wsimport
Gera artefatos portáveis JAX-WS a partir de arquivo WSDL.
xjc
Compila arquivos Esquema XML.
Arquivos de Inclusão
Cabeçalhos C para programas JNI.
Demos
O diretório demo contém diversos subdiretórios que contêm código fonte de amostra, demos, aplicativos e applets que você pode utilizar. |A partir da Versão 6, a demo RMI-IIOP |não é incluída com o SDK.
copyright
O aviso de copyright para o software SDK para Linux.
Licença

O arquivo License, /opt/ibm/java-i386-60/docs/content/<locale>/LA_<locale>, contém o contrato de licença para o software SDK para Linux (em que <locale> é o nome do seu código de idioma, por exemplo, pt). Para exibir ou imprimir o contrato de licença, abra o arquivo em um navegador da Web.

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/java-i386-60/. Os exemplos neste guia assumem que você tenha instalado o Java nesse diretório.

Fazendo Upgrade do SDK

Se você estiver atualizando o SDK a partir de um release anterior, faça backup de todos os arquivos de configuração e arquivos de política de segurança antes de iniciar 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.

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).

No RHEL 4, os RPMs que contêm essas bibliotecas são:

Para incluir essas bibliotecas durante a instalação do RHEL 4:

  1. Quando você chegar à tela Padrões do Pacote, selecione Customizar o Conjunto de Pacotes a Serem Instalados.
  2. 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.
  3. Sob as opções de Desenvolvimento, selecione Desenvolvimento de Software Legado.

Instalando no RHEL (Red Hat Enterprise Linux) 5

O SDK depende de bibliotecas compartilhadas que, por padrão, não são instaladas para o RHEL (Red Hat Enterprise Linux).

No RHEL 5, os RPMs que contêm essas bibliotecas são:

Para incluir essas bibliotecas durante a instalação do RHEL 5:

  1. Na tela de seleção de software, selecione Customizar agora.
  2. Na tela seguinte, no painel esquerdo, selecione Sistema Base; no painel direito, selecione Suporte de Software Legado. Essas seleções instalarão os pacotes compat-libstdc++.
  3. O pacote libXp será necessário, mas não estará disponível para ser selecionado para a instalação na GUI de instalação. Quando a instalação estiver concluída, abra um shell, localize o pacote libXp na mídia de instalação do Red Hat e instale-o. Por exemplo, para instalar em uma plataforma Intel de 32 bits:rpm -i /media/cdrom/Server/libXp-1.0.0-8.i386.rpm

Executando o Java com SELinux no RHEL 5

Para executar o IBM SDK para Java no Red Hat Enterprise Linux Versão 5 com SELinux ativado, o Java deve ser instalado no diretório padrão ou um comando deve ser digitado.

Se o Java não estiver instalado no diretório padrão, digite:

chcon -R -t texrel_shlib_t <path_of_sdk>

Em que <path_of_sdk> é o caminho onde o Java está instalado.

Para obter mais informações sobre SELinux, consulte Introduction to SELinux na documentação do Red Hat.

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. Por exemplo:

/home/username : rpm --queryformat "%{NAME}.%{ARCH}\n" -q libstdc++
libstdc++.x86_64
libstdc++.i386

Instalando a partir de um Arquivo RPM

Um procedimento para instalar a partir de um arquivo RPM.

Para atualizar seu JVM utilizando a ferramenta rpm, é necessário desinstalar qualquer versão anterior. Para instalar duas versões da JVM em diferentes locais, utilize a opção rpm --force para ignorar o conflito de versões ou instale a JVM a partir do arquivo .tgz.

  1. Abra um prompt shell, certificando-se de que você é um usuário root.
  2. Em um prompt de shell, digite rpm -ivh <RPM file>. Por exemplo:
    rpm -ivh ibm-java2-<arq>-sdk-6.0-0.0.<arq>.rpm
    ou
    rpm -ivh ibm-java2-<arq>-jre-6.0-0.0.<arq>.rpm

    Em que <arq> representa sua arquitetura: i386, x86_64, ppc, ppc64, s390 ou s390x.

Instalando a partir de um Arquivo .tgz

Um procedimento para instalar a partir de um arquivo .tgz.

  1. Crie um diretório para armazenar os arquivos do pacote Java. Os exemplos neste guia assumem que você tenha instalado em /opt/ibm/java-i386-60/. No restante do guia, substitua /opt/ibm/java-i386-60/ pelo diretório no qual você instalou o Java.
  2. Em um prompt de shell, digite tar -zxvf <.tgz file>.
    tar -zxvf ibm-java2-sdk-60-linux-<arq>.tgz
    ou
    tar -zxvf ibm-java2-jre-60-linux-<arq>.tgz

    Em que <arq> representa a sua arquitetura: i386, x86_64, ppc, ppc64, s390 ou s390x.

  3. Se você estiver executando o SELinux (Security-Enhanced Linux), identifique as bibliotecas compartilhadas Java para o sistema. Digite:
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/jre
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/bin
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/lib

Utilizando um Formato Compatível de JPackage

o pacote IBM Java também está disponível em um formato compatível do JPackage.

Para simplificar o gerenciamento do SDK, os vários componentes dele estão disponíveis agora como RPMs separados: o Java Runtime Environment, Kit de Desenvolvimento, Plug-in, JDBC, Demo, Som, Origem e Fontes base. RPM "jpackage-utils" (transferível por download de http://jpackage.org), que permite gerenciar vários RPMs Java em um sistema, também é um pré-requisito para os IBM SDKs. Para obter mais informações sobre a especificação do JPackage, consulte http://jpackage.org.

Configurando o SDK e o Runtime Environment para Linux

Inconsistências nas codificações de fontes no Red Hat Advanced Server

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.

Configurando o Caminho

Se você alterar a variável de ambiente PATH, substituirá quaisquer ativadores Java existentes em seu caminho.

A variável de ambiente PATH permite que o Linux localize programas e utilitários, como javac, java e javadoc, a partir de qualquer diretório atual. Para exibir o valor atual do PATH, digite o seguinte em um prompt de comandos:

echo $PATH

Para incluir os ativadores Java em seu caminho:

  1. Edite o arquivo de inicialização do shell em seu diretório inicial (normalmente .bashrc, dependendo do seu shell) e inclua os caminhos absolutos na variável de ambiente PATH; por exemplo:
    export
    PATH=/opt/ibm/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
  2. Efetue logon novamente ou execute o script shell atualizado para ativar a nova variável de ambiente PATH.

Após configurar o caminho, você poderá executar uma ferramenta digitando seu nome em um prompt de comandos a partir de qualquer diretório. Por exemplo, para compilar o arquivo Myfile.Java, em um prompt de comandos, digite:

javac Myfile.Java

Configurando o Caminho de Classe

O caminho de classe informa às ferramentas do SDK, como java, javac e javadoc, onde encontrar as bibliotecas de classe Java.

Você precisa configurar o caminho de classe explicitamente somente se:

Para exibir o valor atual da variável de ambiente CLASSPATH, digite o seguinte comando em um prompt shell:

    echo $CLASSPATH

Se você desenvolve e executa aplicativos que utilizam diferentes ambientes de tempo de execução, incluindo outras versões que você tenha instalado separadamente, deve configurar o CLASSPATH e o PATH explicitamente para cada aplicativo. Se você executa vários aplicativos simultaneamente e utiliza diferentes ambientes de tempo de execução, cada aplicativo deve ser executado em seu próprio prompt shell.

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)

Um procedimento para desinstalar o pacote RPM (Red Hat Package Manager).

Para desinstalar o SDK ou o Runtime Environment para Linux, se você tiver instalado o pacote RPM instalável:

  1. Para verificar quais pacotes RPM você instalou, digite: rpm -qa | grep -i java

    Você verá uma lista de todos os pacotes IBM Java que instalou; por exemplo:

    ibm-java2-<arch>-jre-6.0-0.0.<arch>
    ibm-java2-<arch>-sdk-6.0-0.0.<arch>

    Esta saída indica quais pacotes você pode desinstalar, utilizando o comando rpm -e; por exemplo:

    rpm -e ibm-java2-<arch>-jre-6.0-0.0.<arch>
    rpm -e ibm-java2-<arch>-sdk-6.0-0.0.<arch>

    Como alternativa, você pode utilizar uma ferramenta gráfica, como kpackage ou yast2.

  2. Remova de sua instrução PATH o diretório no qual o SDK e o Runtime Environment foram instalados.
  3. (Linux IA de 32 bits e PPC32 apenas) 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

Uma lista das etapas para remover o IBM SDK para Linux, v6 que foi extraído do pacote compactado.

  1. Remova os arquivos do Runtime Environment ou do Runtime Environment do diretório no qual você instalou o SDK ou o Runtime Environment.
  2. Remova de sua instrução PATH o diretório no qual você instalou o SDK ou Runtime Environment.
  3. Efetue logon novamente ou execute o script shell atualizado para ativar a nova definição de PATH.
  4. (Linux IA de 32 bits e AMD64/EM64T apenas) Se você instalou o Plug-in Java, remova os arquivos do Plug-in Java do diretório do navegador da Web.

Executando Aplicativos Java

Aplicativos Java podem ser iniciados utilizando o ativador java ou através de JNI. Configurações são transmitidas para um aplicativo Java utilizando argumentos da linha de comandos, variáveis de ambiente e arquivos de propriedades.

Comandos java e javaw

Uma rápida visão geral dos comandos java e javaw.

Objetivo

As ferramentas java e javaw ativam um aplicativo Java iniciando um Java Runtime Environment e carregando uma classe especificada.

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.

Uso

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 transmitidos para a função principal.

Os comandos java e javaw têm a seguinte sintaxe:

java [ options ]
<class> [ arguments ... ]
java [ options ] -jar
<file.jar> [ arguments
... ]
javaw [ options ] <class>
[ arguments ... ]
javaw [ options ] -jar
<file.jar> [ arguments
... ]

Parâmetros

[options]
As opções da linha de comandos a serem transmitidas para o ambiente de tempo de execução.
<class>
Classe de inicialização. A classe deve conter um método main().
<file.jar>
Nome do arquivo jar a ser chamado. É utilizado apenas com a opção -jar. O arquivo jar nomeado deve conter arquivos de classe e recurso para o aplicativo, com a classe de inicialização indicada pelo cabeçalho do manifesto Main-Class.
[arguments ...]
Argumentos de linha de comandos a serem transmitidos para a função main() da classe de inicialização.

Obtendo Informações de Versão

O build e o número de versão IBM da sua instalação Java é obtido utilizando a opção -version. |Também é possível obter as informações |de versão para todos os arquivos jar no caminho |de classe, utilizando a opção -Xjarversion.

  1. Abra um prompt shell.
  2. Digite o seguinte comando:
    java -version
    Você verá informações semelhantes a estas:
    java versão "1.6.0-interna"
    Java(TM) SE Runtime Environment (build 20070329_01)
    IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20070326_12091 (JIT ativado)
    J9VM - 20070326_12091_lHdSMR
    JIT  - dev_20070326_1800
    GC   - 20070319_AA)
    As datas exatas do build e as versões serão diferentes.

| |

Você também pode listar as informações de versão |para todos os arquivos jar disponíveis no caminho de classe, no caminho |de classe de inicialização e no diretório de extensões, digitando o seguinte comando:

|
java -Xjarversion
|

Você verá informações semelhantes a estas:

|
...
|/opt/ibm/java-i386-60/jre/lib/ext/ibmpkcs11impl.jar  VERSÃO: 1.0 build_20070125
|/opt/ibm/java-i386-60/jre/lib/ext/dtfjview.jar
|/opt/ibm/java-i386-60/jre/lib/ext/xmlencfw.jar  VERSÃO: 1.00, 20061011  NÍVEL: -20061011
|
|...
|

As informações disponíveis variam para cada arquivo |jar e são extraídas das propriedades |Implementation-Version e |Build-Level contidas no manifesto do arquivo |jar.

Especificando Opções Java e Propriedades de Sistema

Você pode especificar opções Java e propriedades de sistema na linha de comandos, utilizando um arquivo de opções ou uma variável de ambiente.

Estes métodos de especificação de opções Java estão listados por ordem de precedência:

  1. Especificar a opção ou propriedade na linha de comandos. Por exemplo:
    java -Dmysysprop1=tcpip
    -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
  2. Criar um arquivo que contenha as opções e especificá-lo na linha de comandos utilizando -Xoptionsfile=<arquivo>.
  3. Criar uma variável de ambiente denominada IBM_JAVA_OPTIONS contendo as opções. Por exemplo:
    export
    IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait
    -Xdisablejavadump"

As opções à direita da linha de comandos têm precedência sobre as opções à esquerda; por exemplo, se você especificar:

java -Xint -Xjit myClass

A opção -Xjit tem precedência.

Opções Padrão

As definições das opções padrão.

-agentlib:<libname>[=<options>]
Carrega uma biblioteca de agentes nativos <libname>; por exemplo -agentlib:hprof. Para obter informações adicionais, especifique -agentlib:jdwp=help e -agentlib:hprof=help na linha de comandos.
-agentpath:libname[=<options>]
Carrega uma biblioteca de agentes nativos por nome de caminho completo.
-cp <directories and zip or jar files separated by:>
Define o caminho da procura por classes e recursos de aplicativos. Se -classpath e -cp não forem utilizados e a variável de ambiente CLASSPATH não estiver configurada, o caminho de classe do usuário será, por padrão, o diretório atual (.).
-classpath <directories and zip or jar files separated by:>
Define o caminho da procura por classes e recursos de aplicativos. Se -classpath e -cp não forem utilizados e a variável de ambiente CLASSPATH não estiver configurada, o caminho de classe do usuário será, por padrão, o diretório atual (.).
-D<property name>=<value>
Define uma propriedade do sistema.
-help or -?
Exibe uma mensagem de utilização.
-javaagent:<jarpath>[=<options>]
Carrega um agente de linguagem de programação Java. Para obter informações adicionais, consulte a documentação da API java.lang.instrument.
-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.
-showversion
Imprime a versão do produto e continua.
-verbose:<option>
Permite saída interativa.As opções disponíveis são:
class
Grava uma entrada em stderr para cada classe carregada.
gc
Grava informações detalhadas da coleta de lixo em stderr. Utilize -Xverbosegclog para controlar a saída. Consulte o Manual de Diagnóstico para obter mais informações.
jni
Grava informações em stderr descrevendo os serviços da JNI chamados pelo aplicativo e pela JVM.
sizes
Grava informações em stderr descrevendo as configurações de uso da memória ativa.
stack
Grava informações em stderr descrevendo o uso da pilha Java e C para cada encadeamento.
-version
Imprime a versão do produto.
-version:<value>
Exige que a versão especificada seja executada, por exemplo, "1.5".
-X
Imprime a ajuda sobre opções não padrão.

Globalização do Comando Java

Os ativadores java e javaw aceitam argumentos e nomes de classe que contêm qualquer caractere que esteja no 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, utilize a opção de linha de comandos -Xargencoding.

-Xargencoding
Utilize codificação de argumentos. 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).
-Xargencoding:utf8
Utilize codificação UTF8.
-Xargencoding:latin
Utilize codificação ISO8859_1.

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 traduzidas. Essas mensagens diferem com base no código do idioma em que o Java está sendo executado. As descrições detalhadas dos erros e outras informações de depuração retornadas pelo java estão em inglês.

O Compilador JIT (Just-In-Time)

O compilador IBM JIT (Just-In-Time) gera dinamicamente código de máquina para seqüências de bytecodes freqüentemente utilizadas nos aplicativos e applets Java durante a sua execução.O compilador JIT v6 entrega novas otimizações como resultado da pesquisa do compilador, aprimora as otimizações implementadas em versões anteriores do JIT e fornece melhor aproveitamento do hardware.

Tanto o IBM SDK quanto o Runtime Environment incluem o JIT, que é ativado por padrão em aplicativos de usuário e ferramentas SDK. Normalmente, não é preciso chamar o JIT explicitamente; a compilação do bytecode Java para o código da máquina ocorre de modo transparente. É possível desativar o JIT para ajudar a isolar um problema. Se ocorre um problema ao executar um aplicativo Java ou um applet, você pode desativar o JIT para ajudar a isolar o problema. Porém, a desativação é apenas uma medida temporária; o JIT é necessário para otimizar o desempenho.

Para obter mais informações sobre o JIT, consulte o Manual de Diagnóstico.

Desativando o JIT

O JIT pode ser desativado de várias maneiras diferentes. Ambas as opções da linha de comandos substituem a variável de ambiente JAVA_COMPILER.

Desligar o JIT é uma medida temporária que pode ajudar a isolar problemas durante a depuração de aplicativos Java.

Ativando o JIT

O JIT é ativado por padrão. Você pode ativar explicitamente o JIT em uma série de maneiras diferentes. Ambas as opções da linha de comandos substituem a variável de ambiente JAVA_COMPILER.

Determinando se o JIT Está Ativado

Você pode determinar o status do JIT utilizando a opção -version.

Execute o ativador java com a opção -version. Digite o seguinte em um prompt shell:

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 informações adicionais 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 JVM.

Quando o Coletor de Lixo recebe um pedido de armazenamento, a memória não utilizada no heap é colocada à parte, em um processo denominado "alocação". O Coletor de Lixo também procura por áreas de memória que não são mais referenciadas e as libera para reutilização. Isso é conhecido como "coleta".

A fase de coleta pode ser acionada por uma falha na alocação de memória, que ocorre quando nenhum espaço é deixado para um pedido de armazenamento ou por uma chamada System.gc() explícita.

A coleta de lixo pode afetar significativamente o desempenho do aplicativo, por isso a máquina virtual IBM fornece vários métodos para otimizar o modo como a coleta de lixo é realizada, potencialmente reduzindo o efeito no seu aplicativo.

Para obter informações mais detalhadas sobre coleta de lixo, consulte o Manual de Diagnóstico.

Opções de Coleta de Lixo

As opções -Xgcpolicy controlam o comportamento do Coletor de Lixo. Elas fazem trocas entre o rendimento de processamento do aplicativo e do sistema geral e os tempos de pausa causados pela coleta de lixo.

O formato da opção e seus valores são:

-Xgcpolicy:optthruput
(Valor padrão e recomendado.) Proporciona um rendimento de processamento muito alto aos aplicativos, à custa, porém, de pausas ocasionais.
-Xgcpolicy:optavgpause
Reduz o tempo gasto nas 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.
-Xgcpolicy:gencon
Solicita o uso combinado das coletas de lixo simultânea e baseada em gerações para ajudar a minimizar o tempo gasto com qualquer pausa para coleta de lixo.
-Xgcpolicy:subpool
(Somente PPC e zSeries.) Utiliza um algoritmo de alocação de objetos aprimorado para obter melhor desempenho ao alocar objetos no heap. Essa opção melhora o desempenho em sistemas SMP grandes.

Tempo de Pausa

Quando a tentativa de criar um objeto, feita por um aplicativo, não pode ser imediatamente atendida no espaço disponível no heap, o coletor de lixo é responsável pela identificação de objetos não referenciados (lixo), por excluí-los e por 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ânea e coleta de lixo baseada 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 duradouros que não podem ser coletados. Se a coleta de lixo concentrar-se apenas nos objetos com maior probabilidade de serem recicláveis, será possível reduzir ainda mais os tempos de pausa de alguns aplicativos. A Coleta de Lixo Baseada em Gerações reduz os tempos de pausa dividindo o heap em duas "gerações": as áreas de "desenvolvimento" e de "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 talvez não sejam atendidos rapidamente, porque não haverá espaço imediatamente disponível.

Se o heap for operado com capacidade quase cheia, o desempenho do aplicativo poderá ser afetado, independentemente de quais opções de coleta de lixo são utilizadas; e, se os pedidos de mais espaço para o heap continuarem a ser feitos, o aplicativo poderá receber uma exceção OutOfMemoryError, resultando no encerramento da JVM se a exceção não for capturada e tratada. Nesse ponto, a JVM produz um arquivo de Javadumps para utilizar durante o diagnóstico. Nessas condições, recomenda-se aumentar o tamanho do heap utilizando a opção -Xmx ou reduzir o número de objetos em uso.

Para obter mais informações, consulte Manual de Diagnóstico.

Suporte ao Símbolo Euro

O IBM SDK and Runtime Environment define o Euro como moeda padrão para os países da EMU (União Monetária Européia) para datas em ou após 1o de janeiro de 2002. A partir de 1o de janeiro de 2008, Chipre e Malta também terão o Euro como a moeda padrão.

Para utilizar a moeda nacional antiga, especifique -Duser.variant=PREEURO na linha de comandos Java.

Se você estiver executando os códigos de idioma inglês (Reino Unido), dinamarquês ou sueco e desejar utilizar o Euro, especifique -Duser.variant=EURO na linha de comandos Java.

Arquivos de Configuração de Fonte Predefinida

Os arquivos de configuração de fonte predefinida do Linux (fontconfig.RedHat.bfc e fontconfig.SuSE.bfc) são instalados para fornecer as configurações de fonte adequadas para novas distribuições Linux empresariais.

Esses arquivos são somente para sua comodidade. A presença desses arquivos não indica que a nova distribuição Linux seja uma plataforma suportada para o IBM SDK e Runtime Environment para plataformas Linux, Java Technology Edition, Versão 6.

| | |

Utilizando os Métodos de Entrada Indiano e Tailandês

|
|

A partir da Versão 6, os métodos de entrada indiano e |tailandês não estão disponíveis por padrão. Você precisa incluir |manualmente os arquivos jar de método de entrada |no caminho das extensões |Java |para utilizar os métodos de entrada indiano e tailandês.

|

Na Versão 5.0, os arquivos jar de |método de entrada estavam incluídos no diretório |jre/lib/ext |e eram automaticamente carregados pela JVM. Na Versão 6, os arquivos |jar de método de entrada estão incluídos no |diretório |jre/lib/im |e devem ser manualmente incluídos no caminho das extensões |Java |para ativar os métodos de entrada indiano e tailandês. Isso pode ser |conseguido utilizando-se um dos seguintes métodos:

| |

|

Se você instalou o |SDK ou o |Runtime Environment em um |diretório diferente, substitua |/opt/ibm/java-i386-60/ pelo |diretório no qual você instalou o |SDK ou o |Runtime Environment.

Utilizando o SDK para Desenvolver Aplicativos Java

O SDK para Linux contém muitas ferramentas e bibliotecas necessárias para o desenvolvimento de software Java.

Consulte Ferramentas SDK e Informações de Referência para obter detalhes sobre as ferramentas disponíveis.

| | |

Utilizando o XML

|
|

O |IBM |SDK contém os |analisadores XML4J e XL XP-J, o compilador XL TXE-J 1.0 XSLT e o |interpretador XSLT4J XSLT. |Essas ferramentas permitem que você analise, valide, transforme e |serialize documentos XML independentemente de qualquer implementação |de processamento XML específico.

|

|

Utilize localizadores de fábricas para localizar |implementações das classes de fábricas abstratas, conforme descrito |em Selecionando um Processador XML. |Utilizando localizadores de fábricas, você pode selecionar uma |biblioteca XML diferente sem alterar o seu código |Java.

|

| |

Bibliotecas XML Disponíveis

|

O |IBM |SDK para |Java |contém as seguintes bibliotecas XML.

|
|
XML4J 4.5
|
|

XML4J é um analisador de validação que fornece suporte para os |seguintes padrões: |

|
    |
  • XML 1.0 (4a edição)
  • |
  • Namespaces in XML 1.0 (2a edição)
  • |
  • XML 1.1 (2a edição)
  • |
  • Namespaces in XML 1.1 (2a edição)
  • |
  • W3C XML Schema 1.0 (2a Edição)
  • |
  • XInclude 1.0 (2a Edição)
  • |
  • OASIS XML Catalogs 1.0
  • |
  • SAX 2.0.2
  • |
  • DOM Level 3 Core, Load and Save
  • |
  • DOM Level 2 Core, Events, Traversal and Range
  • |
  • JAXP 1.4
| |

XML4J 4.5 é baseado no Apache Xerces-J |2.9.0. Consulte http://xerces.apache.org/xerces2-j/ para obter informações adicionais.

|
|
XL XP-J 1.1
|
|

XL XP-J 1.1 é um analisador de não-validação de alto |desempenho que fornece suporte para StAX 1.0 (JSR 173); uma API |bidirecional para captura-análise e serialização contínua de |documentos XML 1.0 e XML 1.1. Consulte a seção |Informações de Referência de XL XP-J para obter detalhes |adicionais sobre o que é suportado pelo XL XP-J 1.1.

|
|
XL TXE-J 1.0.1 Beta
|
|

Para a Versão 5.0, o |IBM |SDK para |Java |incluiu o compilador e interpretador XSLT4J. |O interpretador XSLT4J era utilizado por padrão.

| |

Para a Versão |6, o |IBM |SDK para |Java |inclui o XL TXE-J. O XL TXE-J inclui o interpretador XSLT4J 2.7.8 e |um novo compilador XSLT. |O novo compilador é |utilizado por padrão. O compilador XSLT4J não é mais incluído com o |IBM |SDK para |Java. |Consulte Migrando para o XL-TXE-J para obter |informações sobre como migrar para o XL TXE-J.

| |

O XL TXE-J |fornece suporte para os seguintes padrões: |

|
    |
  • XSLT 1.0
  • |
  • XPath 1.0
  • |
  • JAXP 1.4
|
|
|

| |

Selecionando um Processador XML

|

A seleção |do processador de XML é realizada por meio de provedores de serviços. |Ao utilizar um localizador de fábrica, o |Java |procura nos seguintes locais para ver qual provedor de serviços |deverá utilizar: |

|
    |
  1. A propriedade de sistema com o mesmo nome do provedor de serviços.
  2. |
  3. Apenas para XMLEventFactory, |XMLInputFactory e |XMLOutputFactory. O valor do provedor de |serviços no arquivo |/opt/ibm/java-i386-60/jre/lib/stax.properties.
  4. |
  5. Para outras fábricas.O valor do provedor de serviços no arquivo |/opt/ibm/java-i386-60/jre/lib/jaxp.properties.
  6. |
  7. O conteúdo do arquivo |META-INF/services/<service.provider>
  8. |
  9. O provedor de serviços padrão.
|

Os seguintes |provedores de serviços controlam as bibliotecas de processamento de |XML utilizadas pelo |Java: |

|
|
javax.xml.parsers.SAXParserFactory
|
Seleciona o analisador SAX. Por padrão, o |org.apache.xerces.jaxp.SAXParserFactoryImpl da |biblioteca do XML4J é utilizado. |
|
javax.xml.parsers.DocumentBuilderFactory
|
Seleciona o construtor de documentos. Por padrão, o |org.apache.xerces.jaxp.DocumentBuilderFactoryImpl |da biblioteca do XML4J é utilizado. |
|
javax.xml.datatype.DatatypeFactory
|
Seleciona a fábrica de tipo de dados. Por padrão, o |org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl |da biblioteca XML4J é utilizado. |
|
javax.xml.stream.XMLEventFactory
|
Seleciona a fábrica de eventos StAX. Por padrão, o |com.ibm.xml.xlxp.api.stax.XMLEventFactoryImpl da |biblioteca XL XP-J é utilizado. |
|
javax.xml.stream.XMLInputFactory
|
Seleciona o analisador StAX. Por padrão, o |com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl da |biblioteca XL XP-J é utilizado. |
|
javax.xml.stream.XMLOutputFactory
|
Seleciona o serializador StAX. Por padrão, o |com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl da |biblioteca XL XP-J é utilizado. |
|
javax.xml.transform.TransformerFactory
|
Seleciona o processador XSLT. Os possíveis valores são: | |
|
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
|
Utilize o compilador XL TXE-J. Esse é o padrão. |
|
org.apache.xalan.processor.TransformerFactoryImpl
|
Utilize o interpretador XSLT4J. |
|
|
|
javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema
|
Seleciona a fábrica do esquema para a linguagem do W3C XML |Schema. Por padrão, o |org.apache.xerces.jaxp.validation.XMLSchemaFactory |da biblioteca XML4J é utilizado. |
|
javax.xml.xpath.XPathFactory
|
Selecione o processador XPath. Por padrão, o |org.apache.xpath.jaxp.XPathFactoryImpl da |biblioteca do XSLT4J é utilizado. |
|

| |

Migrando para o XL-TXE-J

|
|

O compilador XL TXE-J substituiu o interpretador XSLT4J |como o processador XSLT padrão. Siga estas etapas para preparar o |aplicativo para a nova biblioteca.

|

|

O compilador XL TXE-J é mais rápido do que o interpretador XSLT4J quando você está aplicando a mesma transformação mais de uma vez. Se você executa apenas uma transformação a cada vez, o compilador XL TXE-J é mais lento que o interpretador XSLT4J devido ao excesso de compilação e otimização.

|

Para continuar utilizando o interpretador XSLT4J como seu |processador XSLT, configure o provedor de serviços |javax.xml.transform.TransformerFactory como |org.apache.xalan.processor.TransformerFactoryImpl.

|

Para migrar para o compilador XL-TXE-J, siga estas etapas:

|
    |
  1. Utilize |com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl |ao configurar o provedor de serviços |javax.xml.transform.TransformerFactory.
  2. |
  3. Regenere os arquivos de classe gerados pelo compilador XSLT4J. O |XL TXE-J não pode executar arquivos de classe gerados pelo compilador |XSLT4J.
  4. |
  5. Alguns métodos gerados pelo compilador podem exceder o limite de |tamanho do método JVM e, nesse caso, o compilador tentará dividir |esses métodos em métodos menores. | |
      |
    • Se o compilador dividir o método com êxito, você receberá o |seguinte aviso: "Algumas funções geradas excederam o limite do |tamanho do método da JVM e foram automaticamente divididas em funções |menores. Você pode obter um melhor desempenho dividindo manualmente |modelos muito grandes em modelos menores, utilizando a opção |'splitlimit' para o comando Processar ou Compilar ou configurando o |atributo da fábrica de transformadores |'http://www.ibm.com/xmlns/prod/xltxe-j/split-limit'.". Você pode utilizar as classes |compiladas, mas talvez obtenha melhor desempenho controlando o limite |de divisão manualmente.
    • |
    • Se o compilador não dividir o método com êxito, você receberá |uma das seguintes exceções: |"com.ibm.xtq.bcel.generic.ClassGenException: Deslocamento do |destino de ramificação simplesmente muito grande" ou "tamanho de |matriz de bytecode > 65535 no deslocamento=#####". Tente |configurar o limite de divisão manualmente ou utilizando um limite de |divisão inferior.
    Para configurar o limite de divisão, utilize a opção |-SPLITLIMIT ao utilizar os comandos Processar ou |Compilar ou o atributo de fábrica de transformadores |http://www.ibm.com/xmlns/prod/xltxe-j/split-limit |ao utilizar a fábrica de transformadores. O limite de divisão pode estar entre 100 e 2000. Ao configurar o limite de divisão |manualmente, utilize o mais alto limite de divisão possível para |obter um melhor desempenho.
  6. |
  7. O XL TXE-J pode precisar de mais memória que o compilador |XSLT4J. Se você estiver executando sem memória ou o desempenho lhe |parecer lento, aumente o tamanho do heap por meio da opção |-Xmx.
  8. |
  9. Migre seu aplicativo para utilizar as novas chaves de atributos. |As chaves do atributo do gerador de transformadores antigo foram |reprovadas. Os nomes antigos serão aceitos com um aviso. | | |||||||||||||||||||||||||||||||||||||||||||||||||||
    Tabela 1. Alterações nas Chaves de Atributo do Compilador XSL4J para o Compilador XL TXE-J
    Atributo do compilador XSL4J Atributo do compilador XL TXE-J
    translet-name http://www.ibm.com/xmlns/prod/xltxe-j/translet-name
    destination-directory http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory
    package-name http://www.ibm.com/xmlns/prod/xltxe-j/package-name
    jar-name http://www.ibm.com/xmlns/prod/xltxe-j/jar-name
    generate-translet http://www.ibm.com/xmlns/prod/xltxe-j/generate-translet
    auto-translet http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet
    use-classpath http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath
    depuração http://www.ibm.com/xmlns/prod/xltxe-j/debug
    indent-number http://www.ibm.com/xmlns/prod/xltxe-j/indent-number
    enable-inlining Obsoleto no novo compilador
  10. |
  11. Opcional: Para melhor desempenho, certifique-se de que você não esteja recompilando |transformações XSTL que podem ser reutilizadas. Utilize um dos seguintes métodos para reutilizar transformações compiladas: | |
      |
    • Se sua folha de estilo não for alterada no tempo de execução, compile a folha de estilo como parte de seu processo de construção e coloque as classes compiladas em seu caminho de classe. |Utilize o comando org.apache.xalan.xsltc.Compile para compilar a folha de estilo e configure o atributo do gerador do transformador http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath como |true para carregar as classes do caminho de classe.
    • |
    • Se o seu aplicativo utilizará a mesma folha de estilo durante várias execuções, consulte o atributo do gerador do transformador http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet como true para salvar automaticamente a folha de estilo compilada no disco para reutilização. O compilador utilizará uma folha de estilo compilada caso ela esteja disponível, e compilará a folha de estilo se ela não estiver disponível ou estiver desatualizada. |Utilize o atributo do gerador de transformadores http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory |para configurar o diretório utilizado para armazenar folhas de estilo compiladas. |Por padrão, as folhas de estilo são armazenadas no mesmo diretório que o da folha de estilo.
    • |
    • Se o seu aplicativo for um aplicativo de longa execução que reutiliza |a mesma folha de estilo, utilize o gerador de transformadores para compilar |a folha de estilo e criar um objeto Modelos. Você pode utilizar |o objeto Modelos para criar objetos Transformador sem recompilar a folha de estilo. |Os objetos Transformador também podem ser reutilizados |mas não são thread-safe.
| |

Informações de Referência de XML

|
|

As bibliotecas XL XP-J e XL TXE-J XML são novas para a |Versão 6 do SDK. Essas informações de referência descrevem os |recursos suportados por essas bibliotecas.

| | |

Informações de Referência de XL XP-J

|
|

XL XP-J 1.1 é um analisador de não-validação de alto |desempenho que fornece suporte para StAX 1.0 (JSR 173); uma API |bidirecional para captura-análise e serialização contínua de |documentos XML 1.0 e XML 1.1.

|

| |

Recursos Não Suportados
|

Os seguintes |recursos opcionais de StAX não são suportados pelo XL XP-J: |

|

|

| |

Referência a XMLInputFactory
|

As seguintes propriedades são suportadas pela implementação do |javax.xml.stream.XMLInputFactory, conforme |descrito no |XMLInputFactory |Javadoc.

| |||||||||||||||||||||||||||||||||||||||||||
Tabela 2.
Nome da Propriedade Suportado
javax.xml.stream.isValidating Não. O scanner XL XP-J não suporta validação.
javax.xml.stream.isNamespaceAware Sim (suporta verdadeiro e falso). Para |XMLStreamReaders criados a partir de |DOMSources, o processamento de espaço de nomes é |dependente dos métodos que foram utilizados para criar a árvore de |DOM e esse valor não tem nenhum efeito.
javax.xml.stream.isCoalescing Sim
javax.xml.stream.isReplacingEntityReferences Sim. Para XMLStreamReaders |criados a partir de DOMSources, se as entidades já |foram substituídas na árvore de DOM, configurar esse parâmetro não |tem nenhum efeito.
javax.xml.stream.isSupportingExternalEntities Sim
javax.xml.stream.supportDTD Nenhum. DTDs são sempre suportados. Configurar |o valor como falso não tem nenhum efeito.
javax.xml.stream.reporter Sim
javax.xml.stream.resolver Sim
|

O |XL XP-J também suporta o método opcional |createXMLStreamReader(javax.xml.transform.Source), |o que permite que os leitores de StAX sejam criados a partir de |origens DOM e SAX.

|

| |

Referência a XMLStreamReader
|

As seguintes propriedades são suportadas pela implementação do |javax.xml.stream.XMLStreamReader, conforme |descrito no |XMLStreamReader |Javadoc.

| |||||||||||||||||||
Tabela 3.
Nome da Propriedade Suportado
javax.xml.stream.entities Sim
javax.xml.stream.notations Sim
|

O |XL XP-J também suporta a propriedade |javax.xml.stream.isInterning, que retorna um |Booleano, indicando se URIs de nomes e espaço de nomes XML retornadas |pelas chamadas da API foram ou não foram internadas pelo analisador.

|

| |

Referência a XMLOutputFactory
|

As seguintes propriedades são suportadas pela implementação do |javax.xml.stream.XMLOutputFactory, conforme |descrito no |XMLOutputFactory |Javadoc.

| |||||||||||||||
Tabela 4.
Nome da Propriedade Suportado
javax.xml.stream.isRepairingNamespaces Sim
|

| |

Referência a XMLStreamWriter
|

As seguintes propriedades são suportadas pela implementação do |javax.xml.stream.XMLStreamWriter implementation, |conforme descrito no |XMLStreamWriter |Javadoc.

| |||||||||||||||
Tabela 5.
Nome da Propriedade Suportado
javax.xml.stream.isRepairingNamespaces Sim
|

As |propriedades em objetos XMLStreamWriter são de leitura.

| | |

Informações da Referência XL TXE-J

|
|

XL TXE-J é uma biblioteca XSLT que contém o interpretador |XSLT4J 2.7.8 e um compilador XSLT.

|

| |

Tabela de Comparação de Recursos

| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tabela 6. Comparação dos Recursos no Interpretador XSLT4J, o Compilador XSLT4J e o Compilador XL TXE-J.
Recurso Interpretador XSLT4J (incluído) Compilador XSLT4J (não incluído) Compilador XL TXE-J (incluído)
recurso |http://javax.xml.transform.stream.StreamSource/feature Sim Sim Sim
recurso |http://javax.xml.transform.stream.StreamResult/feature Sim Sim Sim
recurso |http://javax.xml.transform.dom.DOMSource/feature Sim Sim Sim
recurso |http://javax.xml.transform.dom.DOMResult/feature Sim Sim Sim
http://javax.xml.transform.sax.SAXSource/feature feature Sim Sim Sim
http://javax.xml.transform.sax.SAXResult/feature feature Sim Sim Sim
http://javax.xml.transform.stax.StAXSource/feature feature Sim Não Sim
http://javax.xml.transform.stax.StAXResult/feature feature Sim Não Sim
recurso |http://javax.xml.transform.sax.SAXTransformerFactory/feature Sim Sim Sim
recurso |http://javax.xml.transform.sax.SAXTransformerFactory/feature/xmlfilter Sim Sim Sim
recurso |http://javax.xml.XMLConstants/feature/secure-processing Sim Sim Sim
atributo |http://xml.apache.org/xalan/features/incremental Sim Não Não
atributo |http://xml.apache.org/xalan/features/optimize Sim Não Não
atributo |http://xml.apache.org/xalan/properties/source-location Sim Não Não
atributo translet-name N/D Sim Sim (com novo nome)
atributo destination-directory N/D Sim Sim (com novo nome)
atributo package-name N/D Sim Sim (com novo nome)
atributo jar-name N/D Sim Sim (com novo nome)
atributo generate-translet N/D Sim Sim (com novo nome)
atributo auto-translet N/D Sim Sim (com novo nome)
atributo use-classpath N/D Sim Sim (com novo nome)
atributo enable-inlining Não Sim Não (obsoleto no TL TXE-J)
atributo indent-number Não Sim Sim (com novo nome)
atributo debug Não Sim Sim (com novo nome)
extensões Java Sim Sim (somente sintaxe abreviada, |construções xalan:component/xalan:script não são suportadas)
extensões JavaScript Sim Não Não
elementos de Extensão Sim Não Não
funções da extensão EXSLT Sim Sim (excluindo dinâmica) Sim (excluindo dinâmica)
extensão redirect Sim Sim (excluindo redirect:open e redirect:close) Sim
extensão output Não Sim Sim
extensão nodeset Sim Sim Sim
funções da extensão NodeInfo Sim Não Não
extensão da biblioteca SQL Sim Não Não
extensão pipeDocument Sim Não Não
extensão evaluate Sim Não Não
extensão tokenize Sim Não Não
XML 1.1 Sim Sim Sim
|

| |

Notas
|

Com o comando Process, utilize |-FLAVOR sr2sw para transformar utilizando o |processamento de fluxos StAX e -FLAVOR er2ew |para processamento de eventos StAX.

|

O novo compilador não |procura pelo provedor de serviços |org.apache.xalan.xsltc.dom.XSLTCDTMManager. |Em vez disso, se StreamSource for utilizado, o |compilador alterna para um analisador XML de alto desempenho.

|

O |Inlining é obsoleto no XL TXE-J. |

| |

A classe |org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl |já não é mais suportada.

| |

Utilizando uma Versão Mais Antiga do Xerces ou Xalan

|
|

Se você estiver utilizando uma versão mais antiga do |Xerces (anterior à 2.0) ou do Xalan (anterior à 2.3) na substituição |confirmada, poderá obter uma NullPointerException |quando iniciar seu aplicativo. Essa exceção ocorre porque essas |versões mais antigas não manipulam corretamente o arquivo |jaxp.properties.

|

|

Para evitar essa situação, utilize uma das seguintes soluções alternativas: |

|

Depurando Aplicativos Java

Para depurar programas Java, utilize o aplicativo JDB (Java Debugger) ou outros depuradores que se comunicam utilizando o JPDA (Java Platform Debugger Architecture), fornecido pelo SDK para Linux.

Informações adicionais sobre o diagnóstico de problemas com o uso do Java podem ser encontradas no Manual de Diagnóstico.

JDB (Java Debugger)

O JDB (Java Debugger) está incluso no SDK para Linux. O depurador é chamado pelo comando jdb; ele é conectado à JVM utilizando o JPDA.

Para depurar um aplicativo Java:

  1. Inicie a JVM com as seguintes opções:
    java -Xdebug
    -Xrunjdwp:transport=dt_socket,server=y,address=<port>
    <class>
    A JVM é iniciada, porém suspende a execução antes de iniciar o aplicativo Java.
  2. Em uma sessão separada, você pode conectar o depurador à JVM:
    jdb -attach <port>
    O depurador será conectado à JVM e você, agora, poderá emitir uma série de comandos para examinar e controlar o aplicativo Java; por exemplo, run para permitir que o aplicativo Java seja iniciado.

Para obter informações adicionais sobre as opções do JDB, digite:

jdb -help

Para obter informações adicionais sobre os comandos do JDB:

  1. Digite jdb
  2. No prompt do jdb, digite help

Você também pode utilizar o JDB para depurar os aplicativos Java em execução em máquinas remotas. O JPDA utiliza soquete TCP/IP para conectar-se à JVM remota.

  1. Inicie a JVM com as seguintes opções:
    java -Xdebug
    -Xrunjdwp:transport=dt_socket,server=y,address=<port>
    <class>
    A JVM é iniciada, porém suspende a execução antes de iniciar o aplicativo Java.
  2. Conecte o depurador à JVM remota:
    jdb -attach <host>:<port>

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 informações adicionais sobre o JDB e o JPDA e seu uso, consulte estes Web sites:

Determinando se o Aplicativo Está Sendo Executado em uma JVM de 32 bits ou de 64 bits

Alguns aplicativos Java devem ser capazes de determinar se estão sendo executados em uma JVM de 32 bits 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 os códigos de 32 bits e de 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:

Você pode verificar a propriedade com.ibm.vm.bitmode a partir do código do seu aplicativo utilizando a chamada:

System.getProperty("com.ibm.vm.bitmode");

Como a JVM Processa Sinais

Quando surge um sinal que é do interesse da JVM, uma rotina de tratamento de sinais é chamada. Esse manipulador de sinais determina se o sinal foi chamado para um encadeamento Java ou não-Java.

Se o sinal for para um encadeamento Java, a JVM assumirá o controle da manipulação do sinal. Se um manipulador de aplicativos para esse sinal estiver instalado e você não tiver especificado a opção de linha de comandos -Xnosigchain, o manipulador de aplicativos para esse sinal será chamado após o término do processamento da JVM.

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, o sinal será ignorado ou a ação padrão será executada.

Com relação aos sinais de exceção e erro, a JVM:

Para obter informações sobre como gravar um ativador que especifique os ganchos acima, consulte: http://www.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:

  1. Chama o manipulador de sinais do aplicativo para esse sinal;
  2. Executa todos os ganchos de encerramento do aplicativo;
  3. Chama todos os ganchos de saída instalados pelo aplicativo;
  4. Executa a limpeza necessária da JVM.

O encerramento é idêntico ao encerramento iniciado por uma chamada para o método Java 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

Os tipos de sinais são Exceções, Erros, Interrupções e Controles.

A Tabela 7 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.
Erros
A JVM fará surgir um SIGABRT caso detecte uma condição da qual não possa recuperar-se.
Interrupções
Os sinais de interrupção surgem de maneira assíncrona, de fora de um processo da JVM, para solicitar encerramento.
Controles
Outros sinais utilizados pela JVM para fins de controle.

Tabela 7. Sinais Utilizados pela JVM
Nome do Sinal Tipo de Sinal Descrição Desativado pelo -Xrs
SIGBUS (7) Exceção Acesso incorreto à memória (alinhamento incorreto de dados) Sim
SIGSEGV (11) Exceção Acesso incorreto à memória (gravar para memória inacessível) Sim
SIGILL (4) Exceção Instrução inválida (tentativa de chamar uma instrução de máquina desconhecida) Não
SIGFPE (8) Exceção Exceção de ponto flutuante (dividir por zero) Sim
SIGABRT (6) Erro Finalização anormal. A JVM emite esse sinal sempre que detecta uma falha da JVM. Sim
SIGINT (2) Interrupção Atenção interativa (CTRL-C). A JVM sai normalmente. Sim
SIGTERM (15) Interrupção Pedido de finalização. A JVM sairá normalmente. Sim
SIGHUP (1) Interrupção Interromper. A JVM sai normalmente. Sim
SIGQUIT (3) Controle Um sinal de saída de um terminal. Por padrão, isso aciona um Javadump. Sim
SIGTRAP (5) Controle Utilizada pelo JIT. Sim
__SIGRTMAX - 2 Controle Utilizada pelo SDK. Não
SIGCHLD (17) 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 do aplicativo Java da Sun.

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, um manipulador 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 seus manipuladores não substituam os manipuladores 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.

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:

A biblioteca libjsig.so também oculta os manipuladores de sinais da JVM do aplicativo. 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 ao manipulador de sinais da JVM; em vez disso, retornam qualquer manipulador que foi instalado antes da inicialização da JVM.

Para utilizar libjsig.so:

A variável de ambiente JAVA_HOME deve ser configurada para o local do SDK, por exemplo,/opt/ibm/java-i386-60/.

Para utilizar libjsig.a:

Escrevendo Aplicativos JNI

Os números de versão válidos da JNI que os programas nativos podem especificar na chamada de API JNI_CreateJavaVM() são: JNI_VERSION_1_2(0x00010002) e JNI_VERSION_1_4(0x00010004).

Restrição: A Versão 1.1 da JNI (Java Native Interface) não é suportada.

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 criada é especificado pelas bibliotecas JSE (isto é, v6). 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/javase/6/docs/technotes/guides/jni/.

Se o seu aplicativo precisar de duas bibliotecas da JNI, uma criada para 32 bits e a outra para 64 bits, utilize a propriedade de sistema com.ibm.vm.bitmode para determinar se você está executando com uma JVM de 32 bits ou de 64 bits e escolha a biblioteca apropriada.

Para compilar e vincular um aplicativo nativo com o SDK, utilize o seguinte comando:

gcc
-I/opt/ibm/java-i386-60/include
-L/opt/ibm/java-i386-60/jre/lib/<arq>/j9vm
-ljvm -ldl -lpthread <JNI program filename>

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.

Suporte para Recuperação de Conectores Bloqueados em Nível de Encadeamento

Quatro novas classes do SDK específicas da IBM foram incluídas no pacote com.ibm.jvm para suportar a recuperação de conectores bloqueados em nível de encadeamento. As novas classes estão empacotadas no core.jar.

Essas classes permitem desbloquear os encadeamentos que tenham sido bloqueados em chamadas de rede ou 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 interrupção de chamadas de sincronização.
Classe Pública InterruptibleIOContext
Uma classe do utilitário para interrupção de chamadas de rede.
Classe Pública InterruptibleThread
Uma classe do utilitário que estende java.lang.Thread para permitir o agrupamento de métodos passíveis de interrupção. Ela utiliza instâncias de InterruptibleLockContext e InterruptibleIOContext para executar os métodos isBlocked() e unblock() necessários, dependendo de uma operação de sincronização ou da rede estar ou não bloqueando o encadeamento.

Ambos, InterruptibleLockContext e InterruptibleIOContext, funcionam referenciando o encadeamento atual. Conseqüentemente, se você não utilizar InterruptibleThread, será necessário fornecer sua própria classe que estende java.lang.Thread para utilizar novas classes.

O Javadoc dessas classes é fornecido com o SDK no diretório docs/content/apidoc.

Configurando a Alocação da Memória de Página Grande

É possível ativar o suporte de página grande, em sistemas que o possuem, 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:     <número de páginas>
HugePages_Free:      <número de páginas>
Hugepagesize:        <tamanho da página, em kB>

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 existirão 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 as páginas grandes não puderem ser alocadas, mesmo quando páginas suficientes estiverem disponíveis, possivelmente as páginas grandes não serão contíguas. A configuração do número de páginas grandes na inicialização as criará contiguamente.

As alocações de páginas grandes terão êxito somente se a JVM tiver acesso root. Para utilizar páginas grandes, execute o Java como raiz ou configure o bit suid do ativador do Java.

Suporte ao CORBA

O Java Platform, Standard Edition (JSE) suporta, no mínimo, as especificações definidas no documento de conformidade da Sun. Em alguns casos, o IBM JSE ORB suporta versões mais recentes das especificações.

As especificações mínimas suportadas estão definidas nas Especificações Oficiais para Suporte CORBA no Java SE 6.

Suporte para GIOP 1.2

Este SDK suporta todas as versões do GIOP, conforme definido nos capítulos 13 e 15 da especificação do CORBA 2.3.1, documento OMG formal/99-10-07.

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 que os serviços ORB podem utilizar para 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 Temporários (o comando tnameserv), quando nenhum parâmetro ORBInitialPort é fornecido, foi alterada de 900 para 2809, que é o número de porta registrado no IANA (Internet Number Authority) para um Serviço de Nomenclatura 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 Nomenclatura Interoperável, e 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 Nomenclatura Interoperável.

O OMG especifica um método ORB::register_initial_reference para registrar um serviço com o Serviço de Nomenclatura Interoperável. No entanto, esse método não está disponível na API do Sun Java Core na Versão 6. 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.

Propriedades de Rastreio

com.ibm.CORBA.Debug=true
Ativa o rastreio do ORB.
com.ibm.CORBA.CommTrace=true
Inclui mensagens GIOP (enviadas e recebidas) no rastreio.
com.ibm.CORBA.Debug.Output=<file>
Especifica o arquivo de saída de rastreio. Por padrão, ele tem o formato orbtrc.DDMMYYYY.HHmm.SS.txt.

Exemplo de Rastreio do ORB

Por exemplo, para rastrear eventos e mensagens GIOP formatadas a partir da linha de comandos, digite:

 java -Dcom.ibm.CORBA.Debug=true
     -Dcom.ibm.CORBA.CommTrace=true <myapp>

Limitações

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 estará funcionando, para que os erros graves 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

O ORB pode ser ajustado para trabalhar bem com a sua rede específica. As propriedades necessárias para ajustar o ORB são descritas aqui.

com.ibm.CORBA.FragmentSize=<tamanho em bytes>
Utilizada para controlar a fragmentação do GIOP 1.2. O tamanho padrão é 1024 bytes.

Para desativar a fragmentação, configure o tamanho do fragmento para 0 bytes:

java -Dcom.ibm.CORBA.FragmentSize=0
<myapp>
com.ibm.CORBA.RequestTimeout=<tempo em segundos>
Configura o tempo máximo de espera por um Pedido do CORBA. Por padrão, o ORB aguarda indefinidamente. Para impedir que as conexões sejam encerradas desnecessariamente, não defina um valor muito baixo para o tempo limite.
com.ibm.CORBA.LocateRequestTimeout=<tempo em segundos>
Configura o tempo máximo de espera por um LocateRequest do CORBA. Por padrão, o ORB aguarda indefinidamente.
com.ibm.CORBA.ListenerPort=<número da porta>
Configura a porta na qual o ORB lerá os pedidos que chegam. 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 para o ORB

Ao executar com um Java SecurityManager, a chamada de alguns métodos nas classes API do CORBA pode fazer com que sejam feitas verificações de permissões, o que talvez resulte em uma SecurityException. Se seu programa utilizar qualquer um desses métodos, assegure-se de que ele tenha as permissões necessárias.

Tabela 8. Métodos Afetados ao Executar com o Java 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. Request invoke java.net.SocketPermission connect
org.omg.CORBA. Request send_deferred java.net.SocketPermission connect
org.omg.CORBA. Request send_oneway java.net.SocketPermission connect
javax.rmi. PortableRemoteObject narrow java.net.SocketPermission connect

Classes de Implementação do ORB

Uma lista das classes de implementação do ORB.

As classes de implementação do ORB neste release são:

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 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 básico para executar comunicações. Isso permite direcionar a interação com quaisquer outros ORBs (Object Request Brokers) do CORBA, independentemente de terem sido implementados em Java ou em outra linguagem de programação.

A seguinte documentação está disponível:

Implementando o Conjunto de Rotinas de Tratamento de Conexão para RMI

O conjunto de encadeamento para Rotinas de Tratamento de Conexão RMI não é ativado por padrão.

Para ativar o conjunto de conexões implementado no nível TCPTransport do RMI, configure a opção

-Dsun.rmi.transport.tcp.connectionPool=true

Essa versão do Runtime Environment não possui uma configuração que possa ser utilizada para limitar o número de encadeamentos no conjunto de conexões.

BigDecimal Avançado

A partir do Java 5.0, a classe IBM BigDecimal foi adotada pela Sun como java.math.BigDecimal. A classe com.ibm.math.BigDecimal está reservada para uma possível utilização futura pela IBM e está reprovada no momento. Migre o código Java existente para utilizar o java.math.BigDecimal.

A nova java.math.BigDecimal utiliza os mesmos métodos que as duas anteriores java.math.BigDecimal e com.ibm.math.BigDecimal. O código existente que utiliza java.math.BigDecimal continua a funcionar corretamente. As duas classes não serializam.

Para migrar o código Java existente para utilizar a classe java.math.BigDecimal, altere a instrução de importação no topo do seu arquivo .java de: import com.ibm.math.*; para import java.math.*;.

Plug-in, Applet Viewer e Web Start

O plug-in Java é utilizado para executar aplicativos Java dentro do navegador. O appletviewer é utilizado para testar aplicativos projetados para serem executados em um navegador. O Java Web Start é utilizado para implementar aplicativos de desktop Java em uma rede e fornece um mecanismo para mantê-los atualizados.

(Somente Linux IA 32-bit e PPC32) Utilizando o Plug-in Java

O Plug-in Java é um Plug-in do navegador da Web. Você utiliza o Plug-in Java, para executar applets 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 Plug-in Java está documentado pela Sun em: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/.

Navegadores Suportados

O plug-in Java suporta SeaMonkey, Mozilla, e Mozilla Firefox.

Tabela 9. Navegadores Suportados pelo Plug-in Java em Linux IA32
Navegador Versões Suportadas
Mozilla 1.7.12, 1.8
Firefox 1.5, 2.0
Tabela 10. Navegadores Suportados pelo Plug-in Java em Linux PPC32
Navegador Versões Suportadas
Mozilla 1.6
|SeaMonkey |1.0.8

Release posteriores secundários de navegadores também são suportados.

Instalando e Configurando o Plug-in Java

Para instalar o plug-in Java, vincule-o simbolicamente para o diretório de plug-in de seu navegador.

O plug-in Java é baseado na iniciativa Open JVM Integration do Mozilla, que é utilizada com a maioria dos produtos e derivativos Mozilla, incluindo o Firefox.

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 as versões 1.4 e posteriores do Mozilla são suportadas.

  1. Efetue login como root.
  2. Altere para o diretório do Plug-in Mozilla(isso pode diferir em algumas distribuições Linux).
  3. Crie um link simbólico para o plug-in.
     ln -s
    /opt/ibm/java-i386-60/jre/plugin/<arq>/ns7/libjavaplugin_oji.so
    .
    Em que <arq> é a arquitetura do sistema.

Para confirmar se o Plug-in Java está disponível e ativado, selecione Ajuda -> Sobre Plug-ins no Mozilla.

É necessário vincular simbolicamente o Plug-in, em vez de copiá-lo, para que ele possa localizar a JVM.

Restrição: Você só pode ter uma biblioteca compartilhada do Plug-in Java em /usr/local/mozilla/plugins/. O Mozilla tentará carregar qualquer coisa que esteja nesse diretório (ou subdiretórios abaixo dele) como um Plug-in, e os resultados serão imprevisíveis se duas versões do Plug-in Java forem carregadas.

Firefox

Estas etapas tornarão o plug-in Java disponível para todos os usuários.

  1. Efetue login como root.
  2. Altere para o diretório de plug-ins do Firefox (isso pode diferir em algumas distribuições Linux).
    cd /usr/local/mozilla-firefox/plugins/
  3. Crie um link simbólico para o plug-in.
     ln -s
    /opt/ibm/java-i386-60/jre/plugin/<arq>/ns7/libjavaplugin_oji.so
    .
    Em que <arq> é a arquitetura do sistema.

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)

Em virtude de limitações em determinados navegadores, talvez não seja possível implementar todas as funções do pacote org.w3c.dom.html.

Um dos seguintes erros será emitido:

Utilizando Parâmetros DBCS

O plug-in Java suporta caracteres de byte duplo (por exemplo, chinês tradicional BIG-5, coreano, japonês) como parâmetros para as tags <APPLET>, <OBJECT> e <EMBED>. Será necessário selecionar a codificação de caracteres 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 <META> tag na seção <HEAD> desta forma:

<meta http-equiv="Content-Type"
content="text/html; charset=big5">

Esse exemplo instrui o navegador para utilizar a codificação de caracteres Chinese BIG-5 para analisar o arquivo HTML.

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

Utilize os seguintes comandos para executar um applet com o Applet Viewer.

Em uma prompt shell, digite:

   appletviewer <nome>

em que <nome> é uma das seguintes opções:

Por exemplo, para chamar o Applet Viewer em um arquivo HTML que chama um applet, digite em um prompt shell:

  
appletviewer $HOME/<filename>.html

Em que filename é o nome do arquivo HTML.

Para chamar o Applet Viewer em uma 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 <META>. Se o arquivo que o Applet Viewer 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. Por exemplo:

appletviewer -encoding JISAutoDetect sample.html

Depurando Applets com o Applet Viewer

É possível depurar applets utilizando a opção -debug do Applet Viewer.

Por exemplo:

cd
demo/applets/TicTacToe
../../../bin/appletviewer
-debug example1.html

É possível localizar documentação sobre como depurar applets utilizando o Applet Viewer no Web site da Sun: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html.

(Somente Linux IA 32-bit, PPC32 e PPC64) Utilizando o Web Start

O Java Web Start é utilizado para a implementação do aplicativo Java.

O Web Start permite ativar e gerenciar aplicativos diretamente a partir da Web. Os aplicativos são armazenados em cache para minimizar os tempos de instalação. Os aplicativos são atualizados automaticamente quando novas versões são disponibilizadas.

O Web Start suporta estes java-vm-args documentados em http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources:

O IBM Web Start também suporta -Xgcpolicy para configurar a política de coleta de lixo.

Para obter informações sobre os navegadores que suportam o Web Start, consulte Navegadores Suportados.

Para obter informações adicionais sobre o Web Start, consulte:

Para obter informações adicionais sobre aplicativos de implementação, consulte:

Executando o Web Start

O Web Start pode ser executado a partir de uma página da Web ou da linha de comandos. Aplicativos Web Start são armazenados no Java Application Cache.

O Java Web Start Versão 6 é instalado automaticamente quando você instala o Java utilizando os pacotes .rpm ou .tgz. Se você extrair o Java do pacote .tgz, execute o script shell jre/lib/javaws/updateSettings.sh para atualizar os arquivos .mailcap e .mime.types no sistema.

É possível chamar o Web Start de várias maneiras diferentes.

(Somente Linux IA 32-bit) Desenvolvimento de Versões Estático Seguro do Web Start

O desenvolvimento de versões estático permite que os aplicativos Web Start requeiram uma versão de JVM específica para sua execução. Como esse recurso também permite que os aplicativos explorem antigas vulnerabilidades de segurança em sistemas que tenham executado upgrade para uma nova JVM, o SSV (Secure Static Versioning) agora é utilizado por padrão.

Com o SSV, o usuário será avisado antes de executar qualquer aplicativo não assinado do Web Start que requeira a utilização de uma JVM específica. Aplicativos assinados e aplicativos que requerem a versão mais recente da JVM são executados normalmente.

Você pode desativar o SSV configurando a propriedade deployment.javaws.ssv.enabled no arquivo deployment.properties como false.

Remessa de Aplicativos Java

Aplicativos Java normalmente consistem em classe, recurso e arquivos de dados.

Quando você envia um aplicativo Java, o pacote de software provavelmente consiste nas seguintes partes:

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 de software do SDK para Linux não permite que você redistribua qualquer dos arquivos do SDK's com o 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 compartilhamento de dados de classe permite que várias JVMs compartilhem um único espaço na memória.

A JVM (Java Virtual Machine) permite o compartilhamento de dados entre JVMs armazenando-os em um arquivo de cache mapeado na memória em disco. O compartilhamento reduz o consumo geral de memória virtual quando mais de uma JVM compartilha um cache. O compartilhamento também reduz o tempo de inicialização de uma JVM após o cache ter sido criado. O cache de classe compartilhada é independente de qualquer JVM ativo e persiste até ele ser destruído.

Um cache compartilhado pode conter:

Visão Geral do Compartilhamento de Dados de Classe

O compartilhamento de dados de classe fornece um método transparente para reduzir a área de cobertura de memória e melhorar o tempo de inicialização de JVM. O |Java |6 fornece recursos novos e melhorados em gerenciamento de cache, |isolamento e desempenho.

Ativando o Compartilhamento de Dados de Classe

Ative o compartilhamento de dados de classe utilizando a opção -Xshareclasses ao iniciar uma JVM. A JVM se conectará a um cache existente ou criará um novo cache, caso não exista um.

Todas as classes de auto-inicialização e de aplicativo carregadas pela JVM são compartilhadas por padrão. Carregadores de classes customizados compartilham classes automaticamente se estenderem o carregador de classes do aplicativo; caso contrário, deverão usar o Java Helper API, fornecido com a JVM para acessar o cache. (Consulte Adaptando Carregadores de Classe Personalizados às Classes de Compartilhamento).

|A JVM também pode armazenar código compilado de AOT (ahead-of-time) |no cache para determinados métodos para melhorar o tempo de |inicialização de JVMs subseqüentes. O código compilado AOT não é |realmente compartilhado entre JVMs, mas é armazenado em cache para |reduzir o tempo de compilação quando a JVM é iniciada. O valor de |código AOT armazenado no cache é determinado heuristicamente. Você |não pode controlar que métodos são armazenados no cache, mas pode |configurar limites superiores e inferiores no valor de espaço de |cache utilizado para código AOT ou pode escolher desativar o |armazenamento em cache AOT completamente. |Consulte Ativando e Configurando o Compartilhamento de Dados de Classe para obter informações adicionais.

Acesso ao Cache

|Uma JVM pode acessar um cache com |acesso de leitura/gravação ou de leitura.Qualquer JVM conectada a um cache com acesso de leitura/gravação pode atualizar o cache. Qualquer número de JVMs pode ler simultaneamente a partir do cache, mesmo enquanto uma outra JVM estiver gravando nele.

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 para obter informações adicionais.

Atualização Dinâmica do Cache

Como o cache de classe compartilhada persiste além do período de existência de qualquer JVM, o cache é atualizado dinamicamente para refletir quaisquer modificações que possam ter sido feitas nos JARs ou nas classes existentes no sistema de arquivos. A atualização dinâmica torna o cache transparente para o aplicativo que está utilizando-o.

Segurança do Cache

O acesso ao cache de classe compartilhada é limitado pelas permissões do sistema operacional e pelas permissões de segurança Java. O cache de classe compartilhada é criado com o acesso do usuário, por padrão, a menos que a subopção da linha de comandos groupAccess seja utilizada. Somente um carregador de classes registrado para compartilhar dados de classe pode atualizar o cache de classe compartilhada.

|A memória cache é |protegida contra distorção acidental ou deliberada utilizando |proteção da página de memória. Essa não é uma garantia absoluta |contra distorção porque a JVM deve desproteger as páginas para gravar |nelas. A única maneira para garantir que um cache não possa ser |modificado é abrí-lo como de leitura.

Se um Java SecurityManager estiver instalado, carregadores de classes, excluídos os carregadores de classes padrão de auto-inicialização, de aplicativo e de extensão, devem obter permissão para compartilhar classes incluindo linhas SharedClassPermission no arquivo java.policy. (Consulte Utilizando SharedClassPermission). A RuntimePermission "createClassLoader" restringe a criação de novos carregadores de classes 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 JVM pode conectar-se a apenas um cache por vez.

Você pode substituir o tamanho do cache padrão na inicialização, utilizando -Xscmx<n><size>; esse tamanho será então 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 o arquivo de cache é excluído manualmente.

Utilitários do Cache

Todos os utilitários do cache são subopções para o comando -Xshareclasses. Consulte Ativando e Configurando o Compartilhamento de Dados de Classe, ou utilize -Xshareclasses:help para ver uma lista das subopções disponíveis.

Ativando e Configurando o Compartilhamento de Dados de Classe

Os utilitários de compartilhamento de dados de classe e de gerenciamento de cache são controlados utilizando opções de linha de comandos para o ativador java.

Para opções que utilizam um parâmetro <size>, coloque o sufixo "k" ou "K" no número para indicar kilobytes, "m" ou "M" para indicar megabytes ou "g" ou "G" para indicar gigabytes.

-Xscmaxaot<tamanho>
Configura o número máximo de bytes no cache que pode ser utilizado para dados AOT. Utilize esta opção para assegurar que uma determinada quantidade de espaço no cache esteja disponível para dados não-AOT. Por padrão, o limite máximo para dados AOT é a quantidade de espaço livre no cache. O valor desta opção não deve ser inferior ao valor de -Xscminaot e nem superior ao valor de -Xscmx.
-Xscminaot<tamanho>
Configura o número mínimo de bytes no cache a ser reservado para dados AOT. Por padrão, nenhum espaço é reservado para dados AOT, embora os dados AOT sejam gravados no cache até que o cache esteja cheio ou até que o limite -Xscmaxaot seja atingido. O valor desta opção não deve ultrapassar o valor de -Xscmx nem de -Xscmaxaot. O valor de -Xscminaot deve sempre ser consideravelmente inferior ao tamanho total do cache porque os dados AOT só podem ser criados para classes armazenadas em cache. Se o valor de -Xscminaot for igual ao valor de -Xscmx, nenhum dado de classe ou dado AOT será armazenado porque dados AOT devem ser associados a uma classe no cache.
-Xscmx<tamanho>
Especifica o tamanho do cache. Esta opção é aplicável somente se um cache estiver sendo criado e se não existir nenhum outro cache com o mesmo nome. O tamanho padrão de cache depende da plataforma. Você pode descobrir o valor de tamanho que está sendo utilizado incluindo -verbose:sizes como argumento da linha de comandos. 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:<subopção>[,<subopção>...]
Ativa o compartilhamento de dados 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. Durante a execução de utilitários de cache, a mensagem "Não foi possível criar a máquina virtual Java" é esperada. Os utilitários de cache não criam a máquina virtual.

Alguns utilitários de cache podem funcionar com caches de versões Java anteriores ou caches criados por JVMs com diferentes larguras de bits. Esses caches são referidos como caches "incompatíveis".

Você pode utilizar as seguintes subopções com a opção -Xshareclasses:

help
Lista todas as subopções da linha de comandos.
name=<nome>
Conecta a um cache de um determinado nome, criando o cache se ele ainda não existir. Também utilizado para indicar o cache que deve ser modificado pelos utilitários de cache, por exemplo, destroy. Utilize o utilitário listAllCaches para mostrar quais caches nomeados estão atualmente disponíveis. Se você não especificar um nome, será utilizado o nome padrão "sharedcc_%u". %u no nome do cache inserirá o nome do usuário atual. Você pode especificar %g no nome do cache para inserir o nome do grupo atual.
|cacheDir=<directory>
|Configura o diretório no qual dados em cache serão lidos e |gravados. Por padrão, <directory> é |/tmp/javasharedresources. |O usuário deve ter permissões suficientes dentro do |<directory>. Por padrão, |o JVM grava arquivos de cache persistentes diretamente no diretório |especificado. Arquivos de cache persistentes podem ser movidos e |excluídos com segurança do sistema de arquivo. |Caches Não |Persistentes são armazenados em |memória compartilhada e têm arquivos de controle que descrevem o |local da memória. Arquivos de controle são armazenados em um |subdiretório javasharedresources do |cacheDir especificado. |Arquivos de controle nesse diretório não devem ser movidos ou |excluídos manualmente. O utilitário |listAllCaches, o utilitário |destroyAll e a subopção |expire funcionam apenas dentro do escopo de um |determinado cacheDir.
|readonly
|Abre um cache existente com permissões de leitura. A JVM não |criará um novo cache com essa subopção. Abrir um cache de leitura |impede que a JVM faça atualizações no cache. Isso também permite que |a JVM conecte-se a caches criados pelos outros usuários ou grupos sem |requerer acesso de gravação. Por padrão, essa subopção não é |especificada.
|nonpersistent
|Utiliza um cache não persistente. Por padrão, a JVM cria um |arquivo de cache em disco que permanece depois que o sistema |operacional reinicia. A subopção nonpersistent |cria o cache em memória compartilhada que está |perdida quando o sistema operacional é encerrado. Caches não |persistentes e persistentes podem ter o mesmo nome, a subopção |nonpersistent deve sempre ser utilizada ao |executar utilitários como destroy em um cache |não persistente. Por padrão, essa subopção não é especificada.
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
Ativa a saída detalhada, o que fornece status geral no cache de classe compartilhado e mensagens de erro mais detalhadas.
|verboseAOT
|Ativa a saída detalhada quando o código AOT compilado está sendo |localizado ou armazenado no cache. O código AOT é gerado |heuristicamente. Pode ser que você não veja código AOT algum para um |aplicativo pequeno. O armazenamento em cache AOT pode ser desativado |utilizando-se a subopção noaot.
verboseIO
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.
verboseHelper
Ativa a saída detalhada para o Java Helper API. Essa saída mostra como a API Helper é utilizada pelo seu ClassLoader.
silencioso
Desliga todas as mensagens de classes compartilhadas, incluindo as mensagens de erro.
nonfatal
Permite que a JVM seja iniciada mesmo que o compartilhamento de dados de classe falhe. O comportamento normal da JVM é recusar-se a ser iniciada se o compartilhamento de dados de classe falhar. Se nonfatal for selecionado e a inicialização do cache de classes compartilhadas falhar, a JVM tentará conectar-se ao cache no modo de leitura. Se isso falhar, a JVM será iniciada sem o compartilhamento de dados de classe.
none
Pode ser incluído no final de uma linha de comandos para desativar o compartilhamento de dados de classe. Esta subopção substitui os argumentos de compartilhamento de classe localizados anteriormente na linha de comandos.
modified=<contexto modificado>
Utilizada quando é instalado um agente da JVMTI que poderia modificar o bytecode no tempo de execução. Se você não especificar esta subopção e um agente de modificação de bytecode for instalado, as classes serão compartilhadas com segurança com um custo de desempenho extra. O <contexto modificado> é um descritor escolhido pelo usuário; por exemplo, "myModification1". Essa opção 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. Consulte Modificação do Bytecode de Tempo de Execução para obter informações adicionais.
|reset
|Faz um cache ser destruído e, em seguida, recriado quando a JVM é |iniciada. Pode ser incluído no final de uma linha de comandos como |-Xshareclasses:reset.
destroy (opção do utilitário)
Destrói um cache especificado pelas subopções name, cacheDir, e nonpersistent. Um cache pode ser destruído somente se todas as JVMs que o utilizam foram encerradas e o usuário tiver permissões suficientes.
destroyAll (opção do utilitário)
Tenta destruir todos os caches disponíveis utilizando as subopções cacheDir e nonpersistent especificadas. Um cache pode ser destruído somente se todas as JVMs que o utilizam foram encerradas e o usuário tiver permissões suficientes.
expire=<tempo em minutos>
Destrói todos os caches que não tenham sido utilizados durante o tempo especificado antes de carregar classes compartilhadas. Essa não é uma opção do utilitário porque ela não faz a JVM sair.
listAllCaches (opção do utilitário)
Lista todos os caches compatíveis e incompatíveis que existem no diretório de cache especificado. Se cacheDir não for especificado, o diretório padrão será utilizado. Informações de resumo, como versão Java e uso atual são exibidas para cada cache.
printStats (opção do utilitário)
Exibe informações de resumo para o cache especificado pelas subopções name, cacheDir e nonpersistent. As informações mais úteis exibidas são o quão completo é o cache e quantas classes ele contém. Classes antigas são classes que foram atualizadas no sistema de arquivos e que foram, portanto, marcadas como "antigas" pelo cache. As classes antigas não são expurgadas do cache e podem ser reutilizadas. Consulte o Manual de Diagnóstico para obter mais informações.
printAllStats (opção do utilitário)

Exibe informações detalhadas para o cache especificado pelas subopções name, cacheDir e nonpersistent. Cada classe é listada na ordem cronológica juntamente com uma referência ao local de onde ela foi carregada. O código AOT para métodos de classes também é listado.

Consulte

Manual de Diagnóstico para obter informações adicionais.

|mprotect=[ all | default | none ]
|Por padrão, as páginas de memória que contêm o cache são |protegidas sempre, a não ser que uma página específica esteja sendo |atualizada. Isso ajuda a proteger o cache contra distorção acidental |ou deliberada. O cabeçalho do cache não é protegido por padrão porque |isso tem um pequeno custo de desempenho. Especificar "all" |assegura que todas as páginas de cache sejam protegidas, incluindo o |cabeçalho. Especificar "none" desativa a proteção da página.
|noBootclasspath
|Impede o armazenamento das classes carregadas pelo carregador de |classe de auto-inicialização no cache de classes compartilhadas. Pode |ser utilizado com a API SharedClassURLFilter para |controlar exatamente quais classes são armazenadas em cache. Consulte o Manual de |Diagnóstico para obter informações adicionais sobre a |filtragem de classes compartilhadas.
|cacheRetransformed
|Ativa o armazenamento em cache de classes que tenham sido |transformadas por meio da utilização da função |RetransformClasses da JVMTI.
|noaot
|Desativa o armazenamento em cache e o carregamento do código AOT.

Criando, Preenchendo, Monitorando e Excluindo um Cache

Uma visão geral do ciclo de vida de um cache de dados de classe compartilhada incluindo exemplos dos utilitários de gerenciamento de cache.

Para ativar o compartilhamento de dados de classe, inclua -Xshareclasses[:name=<nome>] na linha de comandos do aplicativo.

A JVM se conectará a um cache existente com o nome fornecido ou criará um novo cache com aquele 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 duas ou mais JVMs forem iniciadas simultaneamente, todas preencherão o cache simultaneamente.

Para verificar se o cache foi criado, execute java -Xshareclasses:listAllCaches . Para ver quantas classes e quantos dados de classe estão sendo compartilhados, execute java -Xshareclasses:[name=<nome>],printStats. (Esses utilitários podem ser executados após o término da JVM do aplicativo ou em outra janela de comando.)

Para obter feedback adicional sobre o uso do cache durante a execução da JVM, utilize a subopção verbose. Por exemplo, java -Xshareclasses:[name=<nome>],verbose.

Para ver as classes que estão sendo carregadas do cache ou armazenadas no cache, inclua -Xshareclasses:[name=<nome>],verboseIO na linha de comandos do aplicativo.

Para excluir o cache criado, execute java -Xshareclasses:[name=<nome>],destroy. 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. A melhor maneira de determinar o tamanho ideal do cache é especificar um cache grande (utilizando -Xscmx), executar o aplicativo e então utilizar printStats para determinar a quantidade de dados de classe que foi armazenada. Inclua um valor pequeno no valor mostrado em printStats para contingência. Observe que, como as classes podem ser carregadas a qualquer momento durante a existência da JVM, é melhor que essa análise seja feita após o encerramento do aplicativo. Contudo, um cache cheio não provoca um impacto negativo no desempenho ou na capacidade de qualquer JVM a ele conectada; assim é plenamente justificável escolher um tamanho de cache menor do que o requerido.

Se um cache tornar-se cheio, uma mensagem será emitida para a linha de comandos de todas as JVMs que estejam utilizando a subopção detalhado. Todas as JVMs que estejam compartilhando o cache cheio então carregarão quaisquer classes adicionais em sua própria memória de processamento. 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 dados de classe é particularmente útil em sistemas que utilizam mais de uma JVM que executa código semelhante; o sistema se beneficia do consumo de memória virtual reduzido. Também é útil em sistemas que freqüentemente inicializam e encerram JVMs, os quais se beneficiam do aprimoramento no tempo de inicialização.

O código extra para criar e preencher um novo cache é mínimo. O custo em tempo da inicialização de uma única JVM é, em geral, de 0 a 5% mais lento, em comparação com um sistema que não utiliza o compartilhamento de dados de classe, dependendo de quantas classes são carregadas. O tempo de inicialização da JVM com um cache preenchido é, em geral, de 10 a 40% mais rápido, em comparação com sistemas que não utilizam o compartilhamento de dados de classe, dependendo do sistema operacional e do número de classes carregadas. Várias JVMs em execução simultânea apresentarão maiores benefícios de tempo de inicialização total.

As classes duplicadas são consolidadas no cache de classes compartilhadas. Por exemplo, a classe A carregada de myClasses.jar e a classe A carregada de myOtherClasses.jar (com conteúdo idêntico) é armazenada no cache somente uma vez. O utilitário printAllStats mostra várias entradas para classes duplicadas, com cada entrada apontando para a mesma classe.

Quando você executar seu aplicativo com compartilhamento de dados de classe, poderá utilizar as ferramentas do sistema operacional para ver a redução no consumo de memória virtual.

Considerações e Limitações sobre a Utilização do Compartilhamento de Dados de Classe

Fatores a considerar ao implementar o compartilhamento de dados de classe em um produto e utilizar o compartilhamento de dados de classe em um ambiente de desenvolvimento.

Limites no Tamanho do Cache

O tamanho máximo do cache teórico é 2 GB. O tamanho de cache que você pode especificar está limitado pela quantidade de memória física e espaço de paginação disponíveis para o sistema.

O cache para compartilhamento de classes é alocado utilizando o mecanismo de memória System V IPC Shared.

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 pode 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 examinando o arquivo /proc/sys/kernel/shmmax. SHMMAX geralmente é definido como 30 MB.

Modificação do Bytecode de Tempo de Execução

Qualquer JVM utilizando um agente JVMTI (JVM Tool Interface) que possa modificar dados bytecode deve utilizar a subopção modified=<modified_context> se quiser compartilhar as classes modificadas com outra JVM.

O contexto modificado é um descritor especificado pelo usuário que descreve o tipo de modificação que está sendo executada. O contexto modificado particiona o cache de modo que todas as JVMs em execução sob o mesmo contexto compartilhem uma partição.

Esse particionamento permite que as JVMs que não estejam utilizando bytecode modificado compartilhem com segurança um cache com aquelas que estão utilizando bytecode modificado. Todas as JVMs utilizando um determinado contexto modificado devem modificar o bytecode de uma maneira previsível, que possa ser repetida para cada classe, para que as classes modificadas armazenadas no cache tenham as modificações esperadas ao ser carregadas por outra JVM. Qualquer modificação deve ser previsível porque as classes carregadas do cache de classes compartilhadas não podem ser novamente modificadas pelo agente.

Se um agente JVMTI for utilizado sem um contexto de modificação, as classes ainda serão compartilhadas com segurança pela JVM, porém, com um pequeno impacto no desempenho. Utilizar um contexto de modificação com um agente JVMTI evita a necessidade de verificações extras e, portanto, não tem qualquer impacto sobre o desempenho. Um ClassLoader customizado que estende o java.net.URLClassLoader e modifica o bytecode no momento do carregamento sem utilizar a JVMTI, automaticamente armazena esse bytecode no cache, mas o cache não o trata como modificado. Qualquer outra VM que compartilhe esse cache carregará as classes modificadas. A subopção modified=<modification_context> pode ser utilizada da mesma maneira que com os agentes JVMTI para particionar o bytecode modificado no cache. Se um ClassLoader customizado precisar fazer modificações imprevisíveis no momento do carregamento, esse ClassLoader não deve tentar utilizar o compartilhamento de dados de classe.

Consulte o Manual de Diagnóstico para obter mais detalhes sobre este tópico.

Limitações do Sistema Operacional

Não é possível compartilhar classes entre JVMs de 32 e de 64 bits. Deve haver espaço em disco temporário disponível para conter informações de cache. As permissões de cache são impostas pelo sistema operacional.

Para sistemas operacionais que podem executar aplicativos de 32 bits e 64 bits, o compartilhamento de dados de classe não é permitido entre JVMs de 32 bits e 64 bits. A subopção listAllCaches lista caches de 32 bits ou 64 bits, dependendo do modo de endereço da JVM que está sendo utilizada.

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 JVM 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 JVM 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 classe compartilhado são impostas 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 SharedClassPermission

Se um SecurityManager estiver sendo utilizado com compartilhamento de dados de classe e o aplicativo em execução utilizar seus próprios carregadores de classes, esses carregadores de classes deverão obter permissões de classes compartilhadas antes que possam compartilhar classes.

É possível incluir permissões de classes compartilhadas no arquivo java.policy utilizando o nome de classe ClassLoader (os curingas são permitidos) e "read", "write" ou "read/write" para determinar o acesso concedido. Por exemplo:

permission com.ibm.oti.shared.SharedClassPermission
        "com.abc.customclassloaders.*", "read,write";

Se um ClassLoader não tiver as permissões corretas, será impedido de compartilhar classes. Você não pode alterar as permissões da auto-inicialização, aplicativo padrão ou dos carregadores de classes de extensão.

Adaptando Carregadores de Classe Personalizados às Classes de Compartilhamento

Qualquer carregador de classe que estenda java.net.URLClassLoader pode compartilhar classes sem modificação. Carregadores de classes que não estendem java.net.URLClassLoader precisam ser adaptados para compartilhar dados de classe.

Todos os carregadores de classes customizados deverão receber permissões de classes compartilhadas se um SecurityManager estiver sendo utilizado; consulte Utilizando SharedClassPermission. A IBM fornece várias interfaces Java para diversos tipos de carregadores de classes customizados, as quais permitem que os carregadores de classes 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 diretório docs/content/apidoc.

Consulte o Manual de Diagnóstico para obter informações adicionais sobre como utilizar essas interfaces.

Utilizando o JavaComm (Java Communications) API

O pacote JavaComm (Java Communications) API é um pacote opcional fornecido para utilização com o Runtime Environment para Linuxem plataformas IA32, PPC32/PPC64 e AMD64/EM64T. Instale o JavaComm independentemente do SDK ou Runtime Environment.

O JavaComm API fornece aos aplicativos Java uma maneira independente da plataforma de executar as comunicações das portas seriais e paralelas para tecnologias como correio de voz, fax e cartões inteligentes.

A API Java Communications suporta as portas seriais Electronic Industries Association (EIA)-232 (RS232) e as portas paralelas Institute of Electrical and Electronics Engineers (IEEE) 1284 e é suportado em sistemas com o IBM Versão 6 Runtime Environment.

Utilizando a API Java Communications, você poderá:

Instalando a API Java Communications a partir de um Arquivo Compactado

Certifique-se de que o SDK ou Runtime Environment esteja instalado antes de instalar a API Java Communications.

Se você utilizou o pacote RPM para instalar o Java originalmente, instale a API Java Communications a partir do arquivo RPM. Para instalar a API Java Communications a partir de um pacote RPM, consulte Instalando a API Java Communications a Partir de um Arquivo RPM.

Para instalar a API Java Communications a partir de um arquivo compactado:

  1. Coloque o arquivo compactado da API Java Communications no diretório ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz, no diretório onde o SDK ou o Runtime Environment está instalado. Se você instalou no diretório padrão, este é /opt/ibm/java-i386-60/.
  2. Em um prompt shell, no diretório que contém o arquivo compactado, extraia o conteúdo:
    tar -xvzf
    ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz

    Em que <arch> representa sua arquitetura: i386, x86_64, ppc ou ppc64.

  3. |Copie os arquivos javacomm nos diretórios corretos dentro do seu SDK. | |
      |
    1. Copie lib/libLinuxSerialParallel.so em seu diretório jre/bin/.
    2. |
    3. Copie jar/comm.jar em seu diretório jre/lib/ext/.
    4. |
    5. Copie lib/javax.comm.properties em seu diretório jre/lib/.
    Por padrão, o SDK é instalado no diretório /opt/ibm/java-i386-60/.

Instalando a API Java Communications a Partir de um Arquivo RPM

Certifique-se de que uma cópia do SDK ou do Runtime Environment esteja instalada antes de instalar a API Java Communications.

Se você utilizou o pacote RPM para instalar o Java originalmente, instale a API Java Communications a partir do arquivo RPM.

  1. Abra um prompt shell, certificando-se de que você é um usuário root.
  2. Utilize o comando rpm -ivh para instalar o arquivo RPM da API Java Communications. Por exemplo:
    rpm -ivh ibm-javacomm-3.0-0.0.<arq>.rpm
    A API Java Communications é instalada na estrutura de diretórios do /opt/ibm/java-i386-60/.
  3. |Copie os arquivos javacomm nos diretórios corretos dentro do seu SDK. | |
      |
    1. Copie lib/libLinuxSerialParallel.so em seu diretório jre/bin/.
    2. |
    3. Copie jar/comm.jar em seu diretório jre/lib/ext/.
    4. |
    5. Copie lib/javax.comm.properties em seu diretório jre/lib/.
    Por padrão, o SDK é instalado no diretório /opt/ibm/java-i386-60/.

Local dos Arquivos da API Java Communications

Por padrão, os arquivos da API Java Communications são instalados no diretório /opt/ibm/java-i386-60/. Os arquivos e sua estrutura são:

Alterando o Modo de Acesso das Portas Seriais e Paralelas

Após instalar a API Java Communications, você terá que alterar o modo de acesso das portas seriais e paralelas para que os usuários possam acessar esses dispositivos.

Será preciso conceder ao usuário acesso de leitura e gravação aos dispositivos necessários. Efetue login como root e utilize os seguintes comandos, conforme se apliquem:

    chmod 660 /dev/ttyS0    (também conhecido como porta serial COM1)
    chmod 660 /dev/lp0      (também conhecido como porta paralela LPT1)
    chmod 660 /dev/ttyS1    (também conhecido como porta serial COM2)
    chmod 660 /dev/ttyS2    (também conhecido como porta serial COM3)
    chmod 660 /dev/ttyS3    (também conhecido como porta serial COM4)

Inclua usuários específicos no grupo em que os dispositivos residem. Em um sistema SUSE, por exemplo, os dispositivos estão no grupo uucp. Dessa forma, os usuários podem ser incluídos no grupo uucp para obter acesso aos dispositivos.

Altere o modo de acesso de quaisquer outras portas conforme necessário.

Especificando Dispositivos no Arquivo javax.comm.properties

O arquivo javax.comm.properties permite que você especifique os prefixos dos dispositivos que são disponibilizados para a API Java Communications e se eles 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 existirem os dispositivos /dev/ttyS0 e /dev/ttyS1, eles serão alocados em COM1 e COM2.

Para utilizar os conectores seriais USB, 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

A maioria dos ThinkPads tem suas portas seriais desativadas por padrão na BIOS. Atualmente, não há como ativar as portas com o Linux (o pacote tpctl não ativa as portas se elas estiverem desativadas na BIOS).

Par ativar as portas na BIOS, é necessário utilizar a versão DOS do ThinkPad Configuration Utility que está disponível no site de download do IBM ThinkPad. Para utilizar o Utilitário de Configuração do ThinkPad, você vai precisar de um disquete DOS inicializável. Observe que o Utilitário de Configuração do ThinkPad pode ter sido instalado como parte do ThinkPad Utilities no Windows, dependendo das suas opções de instalação, e você pode executá-lo a partir de um prompt de comandos no Windows.

O aplicativo de configuração do ThinkPad fornecido com o Windows tem opções para ativar ou desativar as portas serial e paralela, mas isso não altera também as configurações na BIOS. Assim, se você utilizar este aplicativo com o Windows, as portas estarão disponíveis; entretanto, se você reinicializar o sistema com o Linux, as portas não serão ativadas.

Limitação de Impressão com a API Java Communications

Ao imprimir com a API Java Communications, poderá ser necessário selecionar "Avanço do Papel", "Continuar" ou uma opção semelhante na impressora.

Desinstalando a API Java Communications

O processo utilizado para desinstalar a API Java Communications depende de você ter instalado ou não o pacote instalável do RPM (Red Hat Package Manager) ou o pacote TAR (Tape Archive) compactado.

Desinstalando o Pacote RPM (Red Hat Package Manager)

Desinstalando a API Java Communications utilizando o pacote RPM.

  1. Utilize a ferramenta rpm para desinstalar o pacote. Digite o seguinte comando em um prompt shell:
    rpm -e ibm-javacomm-3.0-0.0
    Como alternativa, você pode utilizar uma ferramenta gráfica, como kpackage ou yast2.
  2. Se o diretório em que a API Java Communications foi instalada não contiver quaisquer outras ferramentas de que você necessita, remova-o da sua instrução PATH.
  3. |Se você tiver copiado as bibliotecas javacomm para o diretório SDK, exclua os arquivos a seguir desse diretório. | |
      |
    • jre/bin/libLinuxSerialParallel.so
    • |
    • jre/lib/ext/comm.jar
    • |
    • jre/lib/javax.comm.properties
    Por padrão, o SDK é instalado no diretório /opt/ibm/java-i386-60/.

Desinstalando o Pacote TAR (Tape Archive) Compactado

Desinstalando a API Java Communications, caso você tenha instalado o pacote TAR compactado.

Exclua os seguintes arquivos do diretório em que os instalou:

Documentação da API Java Communications

Você pode encontrar a documentação da API e amostras da API Java Communications no Web site da Sun.

http://java.sun.com/products/javacomm/.

Serviço e Suporte para Fornecedores Independentes de Software

Pontos de contato para serviço:

Se você estiver qualificado para os serviços do código do Programa relativos ao IBM Solutions Developer Program, entre em contato com o IBM Solutions Developer Program por meio do seu método normal de acesso ou pela Web no endereço: http://www.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 leitores de tela.

Para alterar os tamanhos de fonte nos guias do usuário, utilize a função fornecida com seu navegador, geralmente encontrada sob a opção de menu Visualizar.

Para usuários que necessitem da navegação via teclado, há uma descrição do pressionamento de teclas úteis dos aplicativos Swing em Swing Key Bindings no endereço http://www.ibm.com/developerworks/java/jdk/additional/.

Keyboard Traversal dos Componentes JComboBox no Swing

Se você atravessar a lista drop-down de um componente do JComboBox com as teclas de cursor, o botão ou campo editável do JComboBox não altera o valor até que um item seja selecionado. Esse é o comportamento correto para este release e aprimora a acessibilidade e a usabilidade, assegurando que o comportamento de percurso com o teclado seja consistente com o comportamento de percurso com o mouse.

Acessibilidade do Web Start (Somente Linux IA 32-bit, PPC32 e PPC64)

A partir da Versão 5.0, o Java Web Start contém vários aprimoramentos de acessibilidade e usabilidade, incluindo melhor suporte para leitores de tela e navegação de teclado aprimorada.

Você pode utilizar a linha de comandos apenas para ativar um aplicativo Java 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 configuradas no Java Application Cache Viewer estão disponíveis no arquivo de configuração.

Algum Comentário sobre este Guia do Usuário?

Se você tiver qualquer comentário sobre esse guia do usuário, entre em contato conosco por meio de um dos seguintes canais. Observe que esses canais não estão configurados para responder perguntas técnicas, mas são apenas para comentários sobre a documentação.

Envie seus comentários:

Letras Miúdas. Ao enviar uma mensagem para a IBM, o Cliente concorda que todas as informações contidas em sua mensagem, incluindo dados de feedback como perguntas, comentários, sugestões ou informações similares, serão consideradas não-confidenciais, e a IBM não terá qualquer obrigação, de tipo algum, em relação a tais informações e poderá reproduzir, utilizar, divulgar e distribuir as informações a terceiros sem qualquer limitação. Além disso, a IBM poderá usar todas as idéias, conceitos, conhecimentos ou técnicas contidas em tais informações para qualquer finalidade, incluindo, sem limitação, o desenvolvimento, fabricação e marketing de produtos incorporando tais informações.

Apêndice A. 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 um parâmetro <size>, coloque o sufixo "k" ou "K" no número para indicar kilobytes, "m" ou "M" para indicar megabytes ou "g" ou "G" para indicar gigabytes.

Para opções que utilizam um parâmetro <percentage>, utilize um número de 0 a 1. Por exemplo, 50% é 0,5.

-Xargencoding
Permite colocar seqüências de escape Unicode na lista de argumentos. Por padrão, essa opção é definida como desligada.
-Xbootclasspath:<directories and zip or jar files separated by :>
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:<directories and zip or jar files separated by :>
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:<directories and zip or jar files separated by :>
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, porque essa implementação violaria a licença do código binário do Java 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:classpath
|Exibe uma mensagem de aviso se um erro é descoberto no caminho de |classe, por exemplo, um diretório ou arquivo JAR ausente.
-Xcheck:gc[:<scan options>][:<verify options>][:<misc options>]
Executa verificações adicionais na coleta de lixo. Por padrão, nenhuma verificação é executada. Consulte a saída de -Xcheck:gc:help para obter mais informações.
-Xcheck:jni
Executa verificações adicionais das funções JNI.Por padrão, nenhuma verificação é executada.
|-Xcheck:memory[:<option>]
Identifica fugas de memória no interior da JVM utilizando verificações estritas que fazem com que a JVM seja encerrada no momento da falha. Se nenhuma opção for especificada, all será utilizado por padrão. Consulte a saída de -Xcheck:memory:help ou o Manual de Diagnóstico para obter mais informações.
-Xcheck:nabounds
Executa verificações adicionais das funções JNI.Por padrão, nenhuma verificação é executada.
-Xclassgc
Ativa a coleta de objetos de classe em cada coleta de lixo. Consulte também -Xnoclassgc. Por padrão, esta opção está ativada.
-Xcodecache<tamanho>
Configura o tamanho da unidade da qual são alocados blocos de memória para armazenar código nativo de métodos Java compilados. Um tamanho apropriado pode ser escolhido para o aplicativo em execução. Por padrão, essa seleção é feita internamente, de acordo com a arquitetura da CPU e a capacidade do sistema.
-Xcompactexplicitgc
Desempenha uma compactação para cada chamada para System.gc(). Consulte também -Xnocompactexplicitgc. Por padrão, a compactação ocorre somente quando acionada internamente.
-Xcompactgc
Desempenha uma compactação para cada coleta de lixo. Consulte também -Xnocompactgc. Por padrão, a compactação ocorre somente quando acionada internamente.
-Xconcurrentbackground<number>
Especifica o número de encadeamentos secundários de baixa prioridade anexados para ajudar os encadeamentos do mutador em marcação simultânea. O padrão é 1.
-Xconcurrentlevel<number>
Especifica a taxa "tax" da alocação. Ela indica a proporção entre a quantidade de heap alocado e a quantidade de heap marcado. O padrão é 8.
-Xconmeter:<soa|loa|dynamic>
Determina qual uso da área, LOA (Large Object Area) ou SOA (Small Object Area), é medido e, portanto, quais alocações são taxadas durante a marcação simultânea. A taxa de alocação é aplicada à área selecionada. Se -Xconmeter:dynamic for especificado, o coletor determinará dinamicamente a área a ser medida com base na área que é esgotada primeiro. A opção está configurada, por padrão, como -Xconmeter:soa.
-Xdbg:<options>
Carrega bibliotecas de depuração para suporte da depuração remota de aplicativos. Consulte Depurando Aplicativos Java para obter informações adicionais. A especificação de -Xrunjdwp oferece o mesmo suporte.
-Xdebug
Inicia a JVM com o depurador ativado.Por padrão, o depurador é desativado.
-Xdisableexcessivegc
Desativa a emissão de uma OutOfMemoryError se for gasto tempo excessivo na coleta de lixo. Por padrão, essa opção está 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
Impede que as cadeias existentes na tabela interna de cadeias sejam coletadas. Por padrão, esta opção está desativada.
-Xdisablejavadump
Desliga a geração de Javadumps em erros e sinais. Por padrão, a geração de Javadumps está ativada.
-Xenableexcessivegc
Se for gasto um tempo excessivo na coleta de lixo, esta opção retornará NULL para um pedido de alocação e, assim, fará com que uma OutOfMemoryError seja emitida. Essa ação ocorrerá somente quando o heap tiver sido totalmente expandido e a coleta de lixo esteja ocupando 95% do tempo disponível. Esse comportamento é o padrão.
-Xenableexplicitgc
Sinaliza para a VM que as chamadas para System.gc() devem acionar uma coleta de lixo. Esse é o padrão.
-Xenablestringconstantgc
Permite que as cadeias da tabela interna de cadeias sejam coletadas. Por padrão, esta opção está 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. Consulte Opções de Coleta de Lixo para obter informações adicionais.
-Xgcthreads<number of threads>
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<number>
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<tamanho>
Configura o tamanho inicial da pilha de encadeamentos Java. Por padrão, 2 KB. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
|-Xjarversion
|Consulte Obtendo Informações de Versão.
-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
Aloca uma LOA (Large Object Area). 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<percentage>
<percentage> está entre 0 e 0,95, o que especifica a porcentagem inicial da atual área de objetos antigos alocada para a LOA. O padrão é 0,05 ou 5%.
-Xloamaximum<percentage>
<percentage> está entre 0 e 0,95, o que especifica a porcentagem máxima da atual área de objetos antigos alocada para a LOA. O padrão é 0,5 ou 50%.
-Xlp
Solicita que a JVM aloque 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 Coleta de Lixo: 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 kernels Linux v2.6 ou superior, ou kernels mais antigos em que o suporte de páginas grandes tenha sido 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<percentage>
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. 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 é de 32 KB. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-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 é de 128 KB. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-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 configura a expansão de forma que ela corresponda, pelo menos, ao valor especificado; por exemplo, -Xmine50M configura o tamanho da expansão para, no mínimo, 50 MB. Por padrão, o tamanho mínimo da expansão é de 1 MB.
-Xminf<percentage>
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. Por padrão, o valor mínimo é 0,3 (30%).
-Xmn<tamanho>
Configura os tamanhos inicial e máximo do novo heap (nursery) para o valor especificado ao utilizar -Xgcpolicy:gencon. Configurar -Xmn é equivalente a configurar -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. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-Xmns<tamanho>
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. Esta opção retornará um erro se você tentar utilizá-la com -Xmn. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-Xmnx<tamanho>
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. Esta opção retornará um erro se você tentar utilizá-la com -Xmn. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-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. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-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.
-Xmos<tamanho>
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. Esta opção retornará um erro se você tentar utilizá-la com -Xmo. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-Xmox<tamanho>
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. Esta opção retornará um erro se você tentar utilizá-la com -Xmo. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-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.Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-Xmrx<tamanho>
Define a configuração de tamanho máximo memorizada.
-Xms<tamanho>
Configura o tamanho inicial do heap Java. Você também pode utilizar -Xmo. O padrão é configurado internamente, de acordo com a capacidade do sistema. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-Xmso<tamanho>
Configura o tamanho da pilha C para encadeamentos Java bifurcados. Por padrão, esta opção é configurada para 32 KB em plataformas de 32 bits e para 256 KB em plataformas de 64 bits. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-Xmx<tamanho>
Configura o tamanho máximo do heap Java. Por padrão, esta opção é configurada internamente, de acordo com a capacidade do sistema. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-Xnoclassgc
Desativa coleta de lixo da classe.Esta opção desativa a coleta de lixo do armazenamento associado às classes Java que já não estejam sendo utilizadas pela JVM. Consulte também -Xclassgc. Por padrão, a coleta de lixo da classe é executada.
-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().
-Xnocompactgc
Desativa a compactação para o Coletor de Lixo. Consulte também -Xcompactgc. Por padrão, a compactação é ativada.
-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
Impede a alocação de uma LOA. 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.
-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 equivale a configurar -Xss e -Xmso para o valor especificado.
-Xpartialcompactgc
Ativa a compactação parcial. Por padrão, essa opção não é definida, portanto, todas as compactações são completas. Consulte também -Xnopartialcompactgc.
-Xquickstart
Aprimora o tempo de inicialização atrasando a compilação JIT e as otimizações. Por padrão, o início rápido está desativado e não há atrasos na compilação JIT.
-Xrdbginfo:<host>:<port>
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<library name>[:<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] | [:<option>=<value>, ...]
Executa o perfil do heap, da CPU ou do monitor. Para obter mais informações, consulte Manual de Diagnóstico.
-Xrunjdwp[:help] | [:<option>=< value>, ...]
Carrega bibliotecas de depuração para suporte da depuração remota de aplicativos. Consulte -Xdbg para obter informações adicionais.
-Xrunjnichk[:help] | [:<option>=<value>, ...]
Reprovado, utilize -Xcheck:jni.
-Xscmx<tamanho>
Para obter detalhes sobre o -Xscmx, consulte Ativando e Configurando o Compartilhamento de Dados de Classe.
-Xshareclasses:<options>
Para obter detalhes sobre as opções -Xshareclasses, consulte Ativando e Configurando o Compartilhamento de Dados 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>
Configura o número de coletas de lixo após o qual uma referência temporária será liberada, caso seu referente não tenha 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 máximo de pilha Java para qualquer encadeamento. Por padrão, esta opção é configurada para 256 KB. Utilize a opção -verbose:sizes para obter o valor que a VM está utilizando.
-Xthr:<options>
Define opções de encadeamento.
-Xverbosegclog:<path to file>[X,Y]

Faz com que a saída detalhada da coleta de lixo 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 são inteiros), a saída detalhada da coleta de lixo será redirecionada para um número X de arquivos, cada um contendo um número Y de ciclos de coleta de lixo equivalente à saída detalhada da coleta de lixo. Esses arquivos possuem o formato nome de arquivo1, nome de arquivo2 e assim por diante. Por padrão, nenhuma criação de log de coletas de lixo detalhadas ocorrerá.

Consulte o Manual de Diagnóstico para obter informações adicionais sobre a saída detalhada da coleta de lixo.

-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.

Apêndice B. Limitações Conhecidas

Limitações conhecidas do SDK e do Runtime Environment para Linux.

Você pode encontrar mais ajuda para diagnóstico de problemas no Manual de Diagnóstico no endereço http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.

Configurações da BIOS em 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.

Guia Local da Ferramenta de Monitoramento JConsole

Na ferramenta JConsole da IBM, a guia Local, que permite a conexão com outras VMs (Máquinas Virtuais) no mesmo sistema, não está disponível. Além disso, a opção pid de linha de comandos correspondente não é suportada. Em vez dessa guia, utilize Remoto no JConsole para conectar-se à JVM que você deseja monitorar. Alternativamente, utilize a opção de linha de comandos connection, especificando um host de localhost e um número de porta. Ao ativar o aplicativo que você deseja monitorar, defina estas opções na linha de comandos:

-Dcom.sun.management.jmxremote.port=<value>
Especifica a porta na qual o agente de gerenciamento deve atender.
-Dcom.sun.management.jmxremote.authenticate=false
Desativa a autenticação, a menos que você tenha criado um arquivo de nome do usuário.
-Dcom.sun.management.jmxremote.ssl=false
Desativa a criptografia SSL.

O mecanismo Rhino Javascript Não Está Disponível

O mecanismo Mozilla Rhino Javascript não está incluído com o IBM SDK para Java em virtude de problemas de licenciamento. Para utilizar o mecanismo Rhino Javascript com o IBM SDK para Java, faça download do mecanismo de programação de script jsr223 a partir do https://scripting.dev.java.net/ e do mecanismo Rhino Javascript a partir do Web site do Mozilla: http://www.mozilla.org/rhino/.

Geração Lenta de Par de Chaves DSA

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.

Criando uma JVM Utilizando a JNI

Programas nativos não podem criar uma VM com interfaces JNI_VERSION_1_1(0x00010001). Não é possível chamar JNI_CreateJavaVM() e transmitir-lhe uma versão de JNI_VERSION_1_1(0x00010001). As versões que podem ser aprovadas são:

A VM criada é determinada pelas bibliotecas Java presentes (ou seja, 1.2.2, 1.3.x, 1.4.x, 5.x, 6.x), e não por aquela decorrente da 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.

Gerenciadores de Janelas e Atalhos do Teclado

Seu gerenciador de janelas pode substituir alguns dos atalhos de teclado Java. Se você precisar utilizar um atalho de teclado Java substituído, consulte o manual do sistema operacional e altere os atalhos do teclado do gerenciador de janelas.

Descritores de Arquivos do Sistema Window X

O Sistema Window X não pode utilizar os descritores de arquivo acima do 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.

DBCS e a Área de Transferência KDE

É 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).

Limite em Encadeamentos que Utilizam a Biblioteca do LinuxThreads

No SLES9 e 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:

Entretanto, você poderá ficar sem armazenamento virtual antes de atingir o número máximo de encadeamentos.

Limitação do Tempo de CPU do Usuário do Encadeamento ThreadMXBean

Não há nenhuma maneira de dinstinguir entre o tempo de CPU do modo de usuário e o tempo de CPU do modo de sistema nessa plataforma. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime() e ThreadMXBean.getCurrentThreadCpuTime() todos retornam o tempo de CPU total para o encadeamento necessário.

KeyEvents e os Gerenciadores de Janelas

Os resultados de KeyEvent que incluem a tecla Alt podem diferir entre gerenciadores de janelas no Linux. Além disso, diferem dos resultados de outros sistemas operacionais. Ao utilizar as configurações padrão, Ctrl+Alt+A no gerenciador de janelas KWin produz um KeyEvent, ao passo que Ctrl+Alt+A no gerenciador de janelas Metacity não produz um evento de chave.

O Sistema Window X e a Meta Tecla

No Sistema Linux X Window, o mapa de teclas está configurado como: 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 e Alt estão sendo pressionadas juntas. 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"

Essa alternativa poderá afetar outros aplicativos X-Window que estão sendo executados na mesma tela caso eles utilizem a tecla Meta removida.

SIGSEGV na Criação de uma JVM Utilizando a JNI

Uma chamada para JNI_CreateJavaVM() a partir de um aplicativo JNI pode gerar uma falha de segmentação (sinal SIGSEGV); para evitá-la, reconstrua o programa JNI especificando a opção -lpthread.

Ausência de Recursos com Aplicativos Repletos de Encadeamentos

Se você estiver trabalhando com vários encadeamentos simultâneos, poderá receber 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:

Tente ajustar o sistema para aumentar seus recursos correspondentes.

Problemas de Fonte do Servidor X e Cliente

Ao executar um aplicativo Java AWT ou Swing em uma máquina Linux e exportar a exibição para uma segunda máquina, você poderá enfrentar problemas para 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. Para evitar esse problema, instale as mesmas fontes em ambas as máquinas.

Codificação UTF-8 e MalformedInputExceptions

Se o código de idioma do sistema estiver utilizando uma codificação UTF-8, algumas ferramentas do SDK poderão emitir uma sun.io.MalformedInputException. Para descobrir se o seu sistema está utilizando uma codificação UTF-8, examine as variáveis de ambiente específicas do código de idioma, como LANG ou LC_ALL, para ver se elas terminam com o sufixo ".UTF-8". Se você obtiver essa sun.io.MalformedInputException, altere os caracteres que não estejam no intervalo ASCII de 7 bits (0x00 - 0x7f) e nem representados como caracteres literais Java Unicode para caracteres literais Java Unicode (por exemplo: '\u0080'). Você também pode solucionar alternativamente esse problema removendo o sufixo ".UTF-8" das variáveis de ambiente específicas do código de idioma; por exemplo, se a sua máquina tiver o código do idioma padrão de "en_US.UTF-8", configure LANG como "en_US".

Problemas de AMI e xcin ao Exportar Exibições

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 bits e um de 64 bits ou entre um sistema big-endian e um little-endian) podem ocorrer alguns problemas. Se você tiver esse tipo de problema, faça upgrade para a versão mais recente de AMI e xcin.

RHEL4 e XIM

Apenas para usuários dos idiomas chinês, coreano e japonês do RHEL4.

Nenhum servidor XIM está instalado por padrão. Para inserir caracteres DBCS em um aplicativo Java, instale um pacote de servidor XIM como o iiimf-x ou o kinput2.

RHEL4 e IIIMF

Apenas para usuários dos idiomas chinês, coreano e japonês do RHEL4.

Se você estiver utilizando a IIIMF (Internet/Intranet Input Method Framework), utilize pacotes IIIMF incluídos no Red Hat Enterprise Linux 4 Update 2 ou posterior. Entre em contato com o Red Hat para obter orientação, no site http://www.redhat.com.

(Apenas zSeries de 64 bits) Podem ocorrer falhas de IIIMF ou uma falha ao iniciar. Para resolver o problema, faça upgrade para os pacotes mais recentes de IIIMF.

(Apenas chinês tradicional em PPC, s390 ou s390x) a IIIMF pode não funcionar. Para resolver o problema, utilize iiimf-le-xcin-0.1.7-13.EL4 ou posterior.

(Apenas chinês tradicional em PPC, s390 ou s390x) a IIIMF pode não funcionar corretamente. Para resolver o problema, utilize pacotes de IIMF incluídos no RHEL4 Update 5 ou posterior.

RHEL4 e o Código de Idioma zh_CN.GB18030

Apenas para usuários do idiomas chinês do RHEL4.

O código de idioma zh_CN.GB18030 não é suportado por xlib no RHEL4. xterm não pode ativar o Input Method Server para a entrada de caracteres GB18030. Utilize o código do idioma zh_CN.UTF8. Se você possuir programas ou dados de legado codificados com GB2312, GBK ou GB18030 e desejar migrá-los para o RHEL4, será necessário processá-los previamente com iconv para convertê-los para codificação UTF-8, para que os programas possam ser executados e os dados exibidos adequadamente no RHEL4 com o código de idioma zh_CN.UTF8.

Essa limitação foi solucionada no RHEL4 U3.

RHEL4 e xcin

Podem ocorrer interrupções com xcin no RHEL4. Para resolver o problema, configure ICCHECK_DISABLE como SIM no arquivo /etc/chinese/xcin/xcinrc.

Apenas ambientes de 64 bits

No RHEL4 com xcin (servidor XIM em chinês tradicional), você pode enfrentar um comportamento inesperado, como uma falha de segmentação, com o Java em ambientes de 64 bits (como as plataformas AMD64 ou zSeries de 64 bits). Para resolver o problema, faça upgrade para o pacote mais recentes de xcin.

Problemas de Alteração de Foco no RHEL4 e IIIMF

Apenas RHEL4.

Ao utilizar a IIIMF (Internet Intranet Input Method Framework) para entrada de caracteres DBCS, você pode encontrar problemas de alteração de foco. O problema ocorre durante a minimização de componentes de entrada ativos. Após restaurar o componente, o método de entrada alternará novamente para SBCS. O DBCS deverá, então, ser reativado manualmente.

Os seguintes componentes apresentam esse problema de alteração de foco:

XIM e o Plug-in Java

RHEL4 e SLES9 Apenas

Para usuários dos idiomas japonês, chinês e coreano, não é possível utilizar XIM para inserir seus próprios caracteres nos componentes de texto de um applet Java applet em um navegador da Web. Essa limitação ocorre porque o XEmbed requer uma correção no arquivo da biblioteca X11. Como solução alternativa para essa situação, especifique o parâmetro de sistema -Dsun.awt.noxembed=true para desativar o XEmbed. Você pode utilizar o painel de controle para definir essa opção:

  1. Abra o painel de controle do Plug-in Java e acesse a guia Java.
  2. Clique no botão Exibir nas Configurações do Java Applet Runtime.
  3. Insira -Dsun.awt.noxembed=true nos Parâmetros do Java Runtime e clique em OK.
  4. Clique em Apply.
  5. Inicie um navegador.

Essa limitação foi solucionada no RHEL4 U3 e SLES9 SP3.

Caracteres Arábicos e Placas de Vídeo Matrox

Apenas plataformas Intel de 32 bits

Para usuários de texto arábico, ao utilizar Linux com uma placa de vídeo Matrox e aceleração ativada, a distorção de caracteres pode ocorrer quando da utilização de drawString para exibir fontes grandes. Esse problema é causado pelo driver dessas placas. A solução alternativa é desativar a aceleração do dispositivo.

SLES9 NPTL e o Driver de Porta Paralela

Apenas plataformas Intel de 32 bits

No SLES 9 NPTL, o driver de porta paralela provoca um travamento de kernel e desativa um encadeamento Java. A JVM detecta esse travamento quando tenta suspender o encadeamento para Coleta de Lixo e então trava, produzindo um arquivo de núcleo e a mensagem "JVMLH030: os 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.

Chamadas da JNI com Mais de Oito Parâmetros em Plataformas PPC

Apenas plataformas PPC

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).

Operações de Porta Paralela no SLES9 Anteriores ao SP2

Apenas plataformas PPC

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.

Compilando libFileStat.so em Plataformas PPC de 64 Bits

Apenas plataformas PPC de 64 bits

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<SDK_PATH>/include FileStat.c

em que <SDK_PATH> é o caminho para o diretório SDK instalado.

IPv6 em Plataformas zSeries

Apenas plataformas zSeries

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 IPv6 do Java está incluso neste release, mas é aconselhável desligá-lo com a opção -Djava.net.preferIPv4Stack=true no comando java. Se você instalar um kernel que suporte totalmente o IPv6, essa opção não será necessária.

xcin em Plataformas zSeries de 64 Bits

Apenas plataformas zSeries de 64 bits

O servidor do método de entrada de chinês e taiwanês (xcin) não foi testado.

Java Desktop API

O Java Desktop API pode não funcionar porque uma ou mais bibliotecas GNOME não estão disponíveis.

NullPointerException com a Aparência e Comportamento GTK

Apenas ambientes DBCS

Se o aplicativo falhar com uma NullPointerException utilizando a Aparência e Comportamento GTK, desconfigure a variável de ambiente GNOME_DESKTOP_SESSION_ID.

Alias de Página de Códigos Unicode Shift_JIS

Apenas usuários do idioma japonês

O alias da página de códigos unicode "\u30b7\u30d5\u30c8\u7b26\u53f7\u5316\u8868\u73fe" para Shift_JIS foi removido. Se você utiliza essa página de códigos em seus aplicativos, substitua-a pela Shift_JIS.

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 nesta publicação em outros países. Consulte um representante 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 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:

Para pedidos de licença relacionados a informações de 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 de licença, por escrito, para:

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, 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 seu uso é de responsabilidade do Cliente.

A IBM poderá utilizar ou distribuir qualquer informação recebida do modo que julgar apropriado, sem incorrer em obrigação alguma 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:

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 nesta publicação e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato de Licença do Programa Internacional IBM ou de qualquer outro 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 estes produtos e não pode confirmar a precisão de seu 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 Comerciais

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 comerciais ou marcas de serviço de terceiros.