IBM SDK de 32 bits para plataformas, Java Technology Edition, Versão 6

Guia do SDK and Runtime

Versão 6 Release 0

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

Índice

Prefácio
Visão Geral
Compatibilidade entre Versões
Migrando de outras IBM JVMs
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 Runtime Environment
Antes de Instalar
Instalando os Pacotes
Instalação (Interativa) Assistida
Instalando o Runtime Environment como a Java Virtual Machine do Sistema
Instalação Não-assistida
Ativando o IBM Accessibility Bridge
Desativando o Suporte de Acessibilidade Java
Informações para Usuários de Idiomas Europeus
Configurando o Caminho
Configurando o Caminho de Classe
Desinstalação
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
Executando Automaticamente um Arquivo Java
Executando Aplicativos Java com Tecnologias Assistidas Nativas
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
| |
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
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
Utilizando o Plug-in Java
Navegadores Suportados
Suporte ao SSV (Secure Static Versioning)
Suporte a DOM (Document Object Model)
Utilizando Parâmetros DBCS
Trabalhando com Applets
Executando Applets com o Applet Viewer
CLSIDs Exclusivos
Depurando Applets com o Applet Viewer
Utilizando o Web Start
Executando o Web Start
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
Configurando o Java Communications API
Especificando Dispositivos no Arquivo javax.comm.properties
Limitação de Impressão com a API Java Communications
Desinstalando a API Java Communications
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
Nota Geral Sobre Segurança
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 de 32 bits e Runtime Environment para Windows, 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.

O SDK e o Runtime Environment são suportados nos seguintes produtos:

Esses Ambientes Virtuais são suportados:

Observe que o IPv6 é suportado apenas no Windows XP e Windows Server 2003.

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 Windows, 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 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 Windows não inclui qualquer das ferramentas de desenvolvimento, por exemplo, appletviewer.exe ou o compilador Java (javac.exe), ou classes destinadas apenas aos sistemas de desenvolvimento.

Além disso, o pacote da API (Interface de Programação de Aplicativos) Java Communications é fornecido para utilização com o Runtime Environment para Windows. Informações sobre ele podem ser encontradas em Utilizando o JavaComm (Java Communications) API.

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 de 32 bits para Windows, v6. Não há garantia de que as classes compiladas com este release funcionem com os releases anteriores.

O IBM SDK de 32 bits para Windows, v6, foi desenvolvido com o Microsoft Visual Studio .NET 2003.

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 Windows 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:

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 (Java Native Interface) terão algumas dependências menores.

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 Windows. É 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 C:\Arquivos de Programas\IBM\Java60\bin:
appletviewer.exe (Java Applet Viewer)
Testa e executa applets fora de um navegador da Web.
apt.exe (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.exe (Utilitário Extcheck)
Detecta os conflitos da versão entre um arquivo jar de destino e os arquivos jar de extensão instalados atualmente.
HtmlConverter.exe (Java Plug-in HTML Converter)
Converte uma página HTML que contenha applets para um formato que possa utilizar o Java Plug-in.
idlj.exe (IDL para o Java Compiler)
Gera ligações Java a partir de um determinado arquivo IDL.
ikeycmd.exe (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.exe (Java Archive Tool)
Combina vários arquivos em um único arquivo JAR (Java Archive).
jarsigner.exe (Ferramenta de Assinatura e Verificação JAR)
Gera assinaturas para arquivos JAR e verifica as assinaturas dos arquivos JAR assinados.
java-rmi.exe (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.exe (Java Compiler)
Compila programas escritos na linguagem de programação Java em bytecodes (código Java compilado).
javadoc.exe (Java Documentation Generator)
Gera páginas HTML da documentação de API dos arquivos de origem Java.
javah.exe (Gerador de Cabeçalho C e Arquivo Stub)
Permite associar métodos nativos ao código escrito na linguagem de programação Java.
javap.exe (Class File Disassembler)
Desmonta os arquivos compilados e pode imprimir uma representação dos bytecodes.
javaw.exe (Java Interpreter)
Executa classes Java da mesma maneira que o comando java, mas não utiliza uma janela do console.
javaws.exe (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.exe (Ferramenta de Monitoramento e Gerenciamento JConsole)
Monitora JVMs locais e remotas utilizando uma GUI. Em conformidade com JMX.
jdb.exe (Java Debugger)
Ajuda a depurar seus programas Java.
jdmpview.exe (Formatador dump entre plataformas)
Analisa dumps. Para obter mais informações, consulte Manual de Diagnóstico.
native2ascii.exe (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.exe (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.exe
Cria um arquivo esquema para cada espaço de nomes referenciado nas classes Java.
serialver.exe (Comando da Versão Serial)
Retorna o serialVersionUID para uma ou mais classes em um formato adequado para copiar em uma classe envolvida.
wsgen.exe
Gera artefatos portáveis JAX-WS utilizados em serviços da Web JAX-WS.
wsimport.exe
Gera artefatos portáveis JAX-WS a partir de arquivo WSDL.
xjc.exe
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 Windows.
Licença

O arquivo License, C:\Arquivos de Programas\IBM\Java60\docs\content\<locale>\LA_<locale>, contém o contrato de licença para o software SDK para Windows (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 Runtime Environment

Utilize o assistente de instalação ou o arquivo compactado para instalar o SDK. Configure o SDK utilizando variáveis de ambiente, opções de linha de comandos e arquivos de propriedades.

Antes de Instalar

Para instalar o pacote SDK ou Runtime Environment, faça download do pacote de instalação pertinente. Certifique-se de fazer download de todos os pacotes para o mesmo diretório e de que haja espaço suficiente no diretório temporário.

Os pacotes e seus nomes de arquivo são listados em Instalando os Pacotes; não altere os nomes dos arquivos dos pacotes.

Antes de iniciar a instalação, certifique-se de que há espaço suficiente no diretório C:\WINDOWS\TEMP para uso durante a instalação. A quantidade de espaço temporário necessária no diretório TEMP durante a instalação é:

Se não existir espaço temporário suficiente, o programa de instalação gerará um erro e interromperá a instalação. Se você realmente tiver espaço temporário suficiente mas ainda visualizar esta mensagem, verifique se os pacotes que está tentando instalar foram transferidos completamente por download. Para fazer isto, compare os tamanhos dos arquivos de seus pacotes com os tamanhos dos arquivos mostrados nas páginas da Web utilizadas para download dos pacotes.

Instalando os Pacotes

Há muitos pacotes que podem ser instalados independentemente, incluindo o SDK, o Runtime Environment, Javacomm, documentação e demos.

Os pacotes que você pode instalar são:

Outros pacotes são fornecidos como arquivos compactados:

Se você instalar o SDK ou Runtime Environment a partir do pacote compactado, não poderá utilizar o Web Start ou o plug-in Java e o painel de controle conterá uma guia Update que não funciona.

Instalação (Interativa) Assistida

Utilize a instalação assistida para instalar o SDK ou JRE em um cliente único.

  1. Ative o ibm-java-sdk-60-win-i386.exe (para o SDK) ou o ibm-java-jre-60-win-i386.exe (apenas para o Runtime Environment).
  2. Siga as instruções do assistente de instalação.

    O Runtime Environment é instalado por padrão no diretório C:\Arquivos de Programas\IBM\Java60\jre.

    Se você transferiu por download o pacote SDK instalável, poderá escolher quais componentes serão instalados:

    No assistente de instalação, são apresentadas as seguintes opções:

    No Windows Vista, poderá haver um atraso após selecionar o idioma de instalação.

    Se a instalação falhar com a mensagem de erro "Erro ao aplicar transformação", as informações de configuração do Windows Installer tornaram-se corrompidas. Para corrigir o erro, utilize o Windows Installer Cleanup Utility a partir de http://support.microsoft.com/kb/290301 para remover as informações de configuração do Windows Installer.

Instalando o Runtime Environment como a Java Virtual Machine do Sistema

Quando você instala o Runtime Environment (como parte do pacote instalável SDK ou a partir do pacote instalável Runtime Environment), o programa pergunta se você deseja instalar o Runtime Environment como a JVM (Java Virtual Machine) do sistema. Se você instalá-lo como o sistema JVM, o programa de instalação copia os ativadores java.exe, javacpl.cpl, javaws.exe e javaw.exe no diretório do sistema Windows.

Se uma versão do java.exe ou javaw.exe existir atualmente no diretório do sistema do Windows, será solicitado que você substitua a versão existente pela versão atual. A instalação destes arquivos no diretório do sistema do Windows torna esse Runtime Environment a JVM padrão do sistema. Além disso, a chave de registro "Versão Atual" é configurada para corresponder a essa instalação.

Nota: A instalação do Runtime Environment como a JVM do sistema copia somente a java.exe e javaw.exe para o diretório de sistema do Windows. Nenhum outro programa (como javac.exe ou appletviewer.exe) é copiado.

Instalação Não-assistida

Utilize a instalação não-assistida para instalar o SDK ou JRE em vários clientes.

Para criar uma instalação não-assistida, é necessário concluir primeiro uma instalação assistida e criar um arquivo de resposta (setup.iss) que registra as opções feitas durante a instalação. O arquivo de resposta criado precisa ser correto para os computadores em que será utilizado. Se necessário, crie vários arquivos de resposta para instalação de pacotes em computadores que tenham diferentes configurações.

Para criar um arquivo de resposta durante a instalação, em um prompt de comandos digite:

ibm-java-sdk-60-win-i386 /r

ou

ibm-java-jre-60-win-i386 /r

Dependendo de seu produto Windows, um arquivo de resposta (setup.iss) é criado no diretório C:\Windows ou C:\Winnt.

A seguinte mensagem poderá ser exibida durante uma instalação interativa:

Outro Java Runtime Environment está atualmente
instalado como a JVM do Sistema. Selecione Sim para
substituir esta versão ou Não para sair desta
instalação.

Se esta mensagem for exibida, clicar em Não e saia da instalação. Vá para o diretório do sistema Windows e exclua os dois arquivos a seguir:

Após ter excluído os arquivos, reinicie a instalação interativa, utilizando o comando mostrado no início desta seção.

No sistema no qual você executará a instalação não-assistida, copie o arquivo de resposta setup.iss no diretório C:\Windows. Depois de copiar o arquivo, em um prompt de comandos digite:

ibm-java-sdk-60-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
ibm-java-jre-60-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Nota:
  1. Não há espaços após /f1 ou /f2.
  2. O sinalizador /f1 especifica o nome e a localização do arquivo de resposta. O sinalizador /f2 especifica o nome e a localização do arquivo de log.

Se a instalação for bem-sucedida, o arquivo de log conterá a cadeia ResultCode=0. Se a instalação não for bem-sucedida, o arquivo de log conterá um código de resultado diferente.

Ativando o IBM Accessibility Bridge

O IBM Accessibility Bridge é instalado mas desativado por padrão. Para ativar o IBM Accessibility Bridge, remova o comentário da entrada assistive_technologies no arquivo Accessibility.properties.

O arquivo Accessibility.properties está no diretório jre/lib. Exclua o # do início da seguinte linha:

#assistive_technologies=JawBridge

Este Web site informa sobre os Utilitários de Acessibilidade:

http://java.sun.com/products/jfc/accessibility.html

Desativando o Suporte de Acessibilidade Java

É possível desativar o suporte de Acessibilidade Java para melhorar o desempenho de carregamento dos aplicativos Java de JVM que não fornecem suporte Java de tecnologia assistida, especialmente em links da rede. Para desativar o suporte de Acessibilidade Java, configure a variável de ambiente JAVA_ASSISTIVE como OFF.

Uma tecnologia assistida, como o JawBridge, não ficará disponível se essa variável de ambiente for definida como OFF, mesmo que a tecnologia esteja ativada no arquivo Accessibility.properties.

Informações para Usuários de Idiomas Europeus

No Windows, um processo tem duas páginas de códigos: o página de códigos (ou Windows) e a página de códigos OEM (ou DOS). O comando javaw sempre utiliza a página de códigos ANSI a menos que a propriedade de sistema console.encoding esteja configurada.

A janela de comandos normalmente utiliza a página de códigos OEM. A saída do console Java utiliza a página de códigos da janela de comandos a partir da qual o Java é iniciado. No entanto, o comando javaw sempre utiliza a página de códigos ANSI. Você especifica a página de códigos para utilizar para a saída do console com a opção -Dconsole.encoding no ativador java ou javaw. Por exemplo, -Dconsole.encoding=Cp1252 faz com que todas as saídas do console estejam na página de códigos ANSI Latino 1 (1252) do Windows.

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 Windows 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. Se você instalou o SDK ou o Runtime Environment em C:\Arquivos de Programas\IBM\Java60\, inclua os seguintes diretórios na variável de ambiente PATH:
  2. Feche e reabra qualquer janela de prompt de comandos 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 de comandos:

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

Desinstalação

Utilize o utilitário de programas Adicionar/Remover do Windows para desinstalar o SDK ou Runtime Environment.

Para desinstalar o SDK, caso o tenha instalado utilizando a instalação assistida ou não-assistida:

  1. Dê um clique duplo em Meu Computador no desktop do Windows.
  2. Clique duas vezes em Painel de Controle.
  3. Clique duas vezes em Adicionar ou Remover Programas.
  4. Clique em IBM SKD de 32 bits para Java 2 v6 na lista e depois clique em Alterar/Remover.
  5. Clique em OK.

Esse procedimento remove todos os pacotes que estão instalados com o Instalador. Ele não remove o pacote da API Java Communications (consulte Desinstalando a API Java Communications) ou quaisquer arquivos adicionais que foram extraídos dos pacotes compactados.

Nota: Mensagens de aviso podem ser exibidas notificando que nem todos os arquivos ou entradas de registro, ou ambos, foram removidos. Esses avisos são emitidos porque o Windows considera que determinados arquivos ainda estão em uso; esses arquivos ou entradas de registro, ou ambos, serão removidos durante a próxima reinicialização.

Se você não tiver as permissões necessárias para desinstalar o SDK ou Runtime Environment, "Error1325.launchpad não é um nome do arquivo abreviado válido". Para desinstalar o SDK ou Runtime Environment, restaure as permissões corretas.

Quando várias instalações entre o IBM SDK de 32 bits para Windows, v6 e as versões V1.3.1 e anteriores são mantidas, se você desinstalar a versão anterior enquanto uma versão v6 ainda está instalada no sistema, o desinstalador da V1.3.1 removerá as seguintes chaves de registro, e todas as subchaves, que são exigidas pela versão v6, corrompendo, portanto, a instalação do v6:

Portanto, reinstale o v6 depois de desinstalar a versão V1.3.1. Essa limitação do desinstalador foi corrigida na V1.4.0 e em todas as versões subseqüentes.

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 de comandos.
  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 20070227_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20070226_11758 (JIT ativado) J9VM - 20070226_11758_lHdSMR JIT  - dev_20070215_1800 GC   - 20070208_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:

|
...
|C:\Arquivos de
|Programas\IBM\Java60\jre\lib\ext\ibmpkcs11impl.jar  VERSÃO: 1.0 build_20070125
|C:\Arquivos de
|Programas\IBM\Java60\jre\lib\ext\dtfjview.jar
|C:\Arquivos de
|Programas\IBM\Java60\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:
    set
    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.

Executando Automaticamente um Arquivo Java

Para configurar uma classe Java ou arquivo jar para início automático a partir do Windows Explorer, utilize a opção Ferramentas -> Opções de Pasta -> Tipo de Arquivo do Windows Explorer.

Como alternativa, você pode digitar em um prompt de comandos:

assoc .class=javaclass
ftype
javaclass=C:\Arquivos de
Programas\IBM\Java60\jre\bin\java.exe''%l''%*'

Nota:
  1. O %l e o número 1 e não a letra l.
  2. Se o Java estiver instalado em um diretório diferente do C:\Arquivos de Programas\IBM\Java60\, substitua o diretório de instalação.

Executando Aplicativos Java com Tecnologias Assistidas Nativas

A Sun oferece o Java Access Bridge para fornecer tecnologias assistidas nativas do Windows, como leitores de tela e acesso ao suporte de Acessibilidade Java em um aplicativo Java. Essas tecnologias assistidas nativas do Windows devem suportar chamadas para o Java Access Bridge.

O Java Access Bridge disponibilizado pela Sun inclui um instalador que coloca cinco arquivos nos diretórios corretos: access-bridge.jar, jaccess.jar, accessibility.properties, JavaAccessBridge.dll e WindowsAccessBridge.dll. A IBM envia uma cópia do jaccess.jar no diretório apropriado para uso com o JawBridge.

Se você já tiver ativado o IBM Accessibility Bridge (JawBridge), o qual permite que o recurso Lente de Aumento do Windows 2000 funcione com aplicativos Swing, e desejar ativar o JawBridge ao mesmo tempo que o Java Access Bridge, edite a linha no arquivo accessibility.properties para que seja lido o seguinte:

assistive_technologies=com.sun.java.accessibility.AccessBridge,JawBridge

Marque a linha como comentário inserindo um # no começo da linha para desativar ambas as pontes. Este Web site mostra como fazer o download do Java Access Bridge:

http://java.sun.com/products/jfc/accessibility.html.

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 de comandos:

java -version

Se o JIT não estiver sendo utilizado, será exibida uma mensagem que inclui o seguinte:

(JIT disabled)

Se o JIT estiver sendo utilizado, será exibida uma mensagem que inclui o seguinte:

(JIT ativado)

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

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.

| | |

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 |C:\Arquivos de |Programas\IBM\Java60\ pelo |diretório no qual você instalou o |SDK ou o |Runtime Environment.

Utilizando o SDK para Desenvolver Aplicativos Java

O SDK para Windows 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 |C:\Arquivos de |Programas\IBM\Java60\jre\lib\stax.properties.
  4. |
  5. Para outras fábricas.O valor do provedor de serviços no arquivo |C:\Arquivos de |Programas\IBM\Java60\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 Windows.

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 Windows. 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_shmem,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_shmem,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 -connect
    com.sun.jdi.SocketAttach:hostname=<host>,port=<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.

Nas situações em que um sinal é gerado externamente (por exemplo, quando você pressiona CTRL-BREAK), um novo encadeamento é criado para o manipulador de sinais. Nesse caso, a rotina de tratamento de sinal da JVM executa seu processamento e, se uma rotina de tratamento de aplicativo para esse sinal for instalada e você não tiver especificado a opção de linha de comandos -Xnosigchain, essa rotina de tratamento de aplicativo será chamada.

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 é SIGBREAK, o que faz com que um Javadump seja gerado.

Sinais Utilizados pela JVM

Os tipos de sinais são 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
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
SIGBREAK Controle Um sinal de pausa proveniente de um terminal. Por padrão, isso aciona um Javadump. Sim

AIBM JVM utiliza a exceção estruturada ao manipular as API e SetConsoleCtrlHandler(). Essas são desativadas com -Xrs. -Xnosigchain é ignorado no Windows.

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 2 (SIGINT) e 15 (SIGTERM) nos encadeamentos da JVM fazem com que ele seja encerrada. Assim, um manipulador de sinais de aplicativo não deve tentar uma recuperação desse sinal 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 jsig.dll antes da biblioteca compartilhada msvcrt.dll. A biblioteca jsig.dll assegura que as chamadas para signal() sejam interceptadas para que suas rotinas de tratamento não substituam as rotinas de tratamento de sinais da JVM. Em vez disso, essas chamadas salvam as novas rotinas de tratamento de sinais ou as "encadeia" ocultas sob as rotinas de tratamento instaladas pela JVM. Mais tarde, quando qualquer um desses sinais surgir e for verificado que eles não se destinam à JVM, as rotinas de tratamento pré-instaladas serão chamadas.

A biblioteca libjsig.dll 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.

A variável de ambiente JAVA_HOME deve ser configurada para o local do SDK, por exemplo,C:\Arquivos de Programas\IBM\Java60\.

Para utilizar jsig.dll, efetue o link com o aplicativo que cria ou incorpora uma JVM.

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.

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.

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.

As alocações de páginas grandes terão êxito somente se a política administrativa local para o usuário da JVM estiver configurada para permitir "Bloquear páginas na memória".

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.

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 Internet Explorer, Netscape, Mozilla, e Mozilla Firefox.

Tabela 9. Navegadores Suportados pelo Plug-in Java
Navegador Versões Suportadas
Internet Explorer 6.0 SP1, 7.0
Netscape (Não suportado em Windows Vista) 7.2
Mozilla (Não suportado em Windows Vista) 1.7, 1.8
Firefox 2.0

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

Internet Explorer 5.01, o navegador padrão em Windows 2000, não é suportado.

Suporte ao SSV (Secure Static Versioning)

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

Por padrão, todos os applets são executados na JVM mais recentemente instalada. Para desativar o SSV, configure a seguinte chave de registro como 0:

HKEY_LOCAL_MACHINE\Software\IBM\Java Deployment\Policy\EnableSecureStaticVersioning

Se a chave de registro não existir, o SSV será ativado.

O SSV não funcionará se as extensões de navegador de terceiros estiverem desativadas no Internet Explorer. Para ativar as extensões de navegador de terceiros:

  1. Abra o Internet Explorer.
  2. Clique em Ferramentas -> Opções da Internet.
  3. Clique na guia Avançado.
  4. Selecione a caixa de opção Ativar extensões de navegador de terceiros.

Se as extensões de navegador de terceiros estiverem desativadas após o SSV ter sido utilizado, o SSV continuará a funcionar.

Para fornecer proteção para os navegadores Mozilla e Firefox, o Plug-in para Internet Explorer removerá automaticamente todos os Plug-ins Java dos diretórios de Plug-in do Mozilla e do Firefox. Isso acontecerá toda vez que um applet for executado no Internet Explorer.

Para reinstalar um Plug-in Java para Mozilla ou Firefox, utilize o Painel de Controle do Java.

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 de comandos, 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 de comandos:

appletviewer <demo>\GraphLayout\example1.html

Em que <demo> é substituído pelo caminho completo do local em que você descompactou o pacote demo.

Para chamar o Applet Viewer em uma página da Web, digite em um prompt de comandos:

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

CLSIDs Exclusivos

Um conjunto exclusivo de CLSIDs foi adicionado à IBM JVM a partir da Versão 6.

Os novos CLSIDs são os seguintes:

1ACECAFE-0016-0000-0000-ABCDEFFEDCBA
1ACECAFE-0016-0000-0000-ABCDEFFEDCBB
1ACECAFE-0016-0000-0000-ABCDEFFEDCBC

Você pode consultar os CLSIDs acima na Tag OBJECT dos seus applets.

Além disso, os seguintes CLSIDs existentes também são suportados para fins de compatibilidade:

CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA
CAFEEFAC-0016-0000-0000-ABCDEFFEDCBB
CAFEEFAC-0016-0000-0000-ABCDEFFEDCBC

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.

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.

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

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 Windows. O software SDK para Windows contém um Runtime Environment. No entanto, você não pode assumir que os usuários tenham o software SDK para Windows instalado.

A licença de software do SDK para Windows 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 Windows 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. 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.
|cacheDir=<directory>
|Configura o diretório no qual dados em cache serão lidos e |gravados. Por padrão, <directory> é |o diretório do usuário C:\Documents |and Settings\<username>\Local |Settings\Application Data\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 |faz que o arquivo de cache seja |excluído 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.
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. Em sistemas de arquivos NTFS, a opção expire é exata para a hora mais próxima.
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 do cache que você pode especificar está limitado pela quantidade de espaço em disco e espaço de endereço virtual disponíveis.

O cache é limitado pelos seguintes fatores:

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 no diretório de perfil do usuário. 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.

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

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-javacomm-3.0-0.0-win-i386.zip, no diretório onde o SDK ou o Runtime Environment está instalado. Se você instalou no diretório padrão, este é C:\Arquivos de Programas\IBM\Java60\.
  2. Extraia o arquivo compactado. A API Java Communications é extraída nos subdiretórios dentro do diretório existente.
  3. |Copie os arquivos javacomm nos diretórios corretos dentro do seu SDK. | |
      |
    1. Copie lib\win32com.dll 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 C:\Arquivos de |Programas\IBM\Java60\.
  4. |Inclua comm.jar em seu caminho de classe. Isto não é necessário para uma instalação do JRE. | |
      |
    • Se você não tiver um caminho de classe definido: set CLASSPATH=\jre\lib\ext\comm.jar
    • |
    • Se você já tiver um caminho de classe definido: set CLASSPATH=\jre\lib\ext\comm.jar;%classpath%

Configurando o Java Communications API

Após instalar o Java Communications API, você deve:

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.

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

Para desinstalar a API Java Communications, exclua os seguintes arquivos do diretório em que o Runtime Environment foi instalado:

Por padrão, o Runtime Environment é instalado no diretório C:\Arquivos de Programas\IBM\Java60\.

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

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, Application Data\IBM\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.

Nota Geral Sobre Segurança

Você pode obter os arquivos de políticas de jurisdição irrestrita JCE em http://www.ibm.com/developerworks/java/jdk/security/index.html. A documentação sobre os pacotes de segurança JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS e criptografia de hardware da IBM também está disponível nesse Web site.

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>
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 (Windows 2003)
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'. As páginas grandes são suportadas por sistemas que executam o Windows 2003, nos quais o sistema operacional tenha sido configurado para utilizar páginas grandes. 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 Windows.

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.

Problemas de Fonte em Códigos de Idioma Suportados

O IBM SDK de 32 bits para Windows, v6 suporta os seguintes códigos do idioma:

Entretanto, as fontes desses códigos do idioma podem não funcionar nos componentes do AWT.

Utilização de Soquetes com o IPv6

O IBM SDK de 32 bits para Windows, v6 suporta o IPv6. No entanto, como o suporte atual do IPv6 no Windows não é dual-stack, o SDK emula o comportamento dual-stack em um sistema ativado por IPv6. Seu aplicativo Java pode utilizar até o dobro de soquetes devido à natureza da emulação. Para desativar essa emulação, desative o suporte do IPv6 no SDK configurando a propriedade de sistema java.net.preferIPv4Stack como true.

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

IME (Input Method Editor)

Ao trabalhar com um IME (Input Method Editor), recomenda-se que a composição dos caracteres seja completada e que o candidato selecionado antes de utilizar a área de trabalho para qualquer outra operação.

Quando um usuário digita um texto em uma Área de Texto AWT enquanto utiliza um IME e, em seguida, redimensiona a janela do aplicativo antes de consolidar o texto, esse texto será automaticamente consolidado.

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.

Firewalls Pessoais

Firewalls pessoais podem causar problemas ao código NIO do Windows, fazendo com que operações específicas falhem. Por exemplo, a chamada de método Selector.open() pode emitir uma "java.io.IOException: Unable to establish loopback connection" com uma causa de "java.net.ConnectException: Connection refused: connect". A exceção é causada pela conexão do sistema operacional em uma porta que esteja sendo bloqueada pelo firewall. O JVM tentará novamente a operação de conexão, solicitando ao sistema operacional para escolher um número de porta diferente. Se a conexão ainda não for possível após várias tentativas, uma ConnectException será emitida.

Se você vir essa exceção, poderá definir a propriedade do sistema java.nio.debug=pipe para ver quais números de porta estão sendo bloqueados.

Esgotamento da Identificador de Arquivos

No Windows 2000 e XP, O valor padrão do número de arquivos que podem ser abertos simultaneamente é muito baixo e causará problemas a aplicativos com E/S intensa. Para corrigir essa limitação, edite o arquivo <windows>\system32\CONFIG.NT e configure os seguintes valores:

files=200buffers=60

em que <windows> é o diretório no qual oWindows está instalado.

Problemas do DirectDraw e do Ponteiro do Mouse

No Windows 2000, com uma profundidade de cores de 32 bits, o mecanismo DirectDraw da JVM não volta a pintar a área sob o ponteiro do mouse. O efeito são quadrados cinza ou preto que aparecem nos menus depois de o mouse ter estado ali. A solução alternativa é desativar o DirectDraw (-Dsun.java2d.noddraw) ou alterar a resolução de cores da tela para algum outro valor, como 256 cores.

Problemas da Conexão NIO

A chamada NIO SocketChannel finishConnect() pode retornar verdadeiro (o canal está conectado) ou falso (o processo de conexão não está concluído ainda) ou pode emitir uma exceção. No Windows 2000, ao utilizar conexões sem bloqueio, false poderá ser retornado mesmo depois de uma chamada Java select() anterior ter indicado que um canal estava pronto para processamento.

Intervalo de Pilhas do Encadeamento Principal

Não é possível alterar o intervalo de pilhas do encadeamento principal Java (também conhecido como encadeamento primordial) no tempo de execução. O encadeamento principal possui um tamanho fixo de 256 KB, determinado como o valor ótimo por motivos de desempenho. Você pode usar a opção -Xss para modificar o intervalo de pilhas somente em encadeamentos que não sejam o principal. Não utilize o encadeamento principal para cálculos excessivamente recursivos pois o encadeamento principal é mais propenso ao estouro de pilha que outros encadeamentos.

Caracteres DBCS

Se você estiver digitando caracteres DBCS em um JTextArea, JTextField ou JFileChooser, a alternância de alguns IMEs chineses (especialmente Chinese Internal Code e Zhengma) para o IME Intelligent ABC pode fazer com que seja produzido um dump de núcleo.

Instalação do Idioma Tcheco

Para usuários Tchecos, observem que o painel de seleção de idiomas do InstallShield oferece uma entrada traduzida em uma instalação normalmente não traduzida. Essa limitação é causada pelo InstallShield. A cadeia é capturada do sistema operacional com base na página de códigos. Como os idiomas polonês (para o qual a instalação foi traduzida) e tcheco possuem ambos a página de códigos 1250, o InstallShield tenta recuperar uma lista de idiomas do sistema para os dois idiomas, resultando nessa cadeia na lista de idiomas.

Chinês Tradicional e Comando More

Se você utilizar o chinês tradicional, não canalize a saída do aplicativo Java diretamente no comando more. Em vez disso, direcione-a para um arquivo temporário e exiba o arquivo separadamente.

Distorção de Acentuação para Usuários Catalães

Para usuários catalães, a fonte Lucida Console deve ser utilizada para impedir a má exibição de caracteres maiúsculos acentuados. Esse problema afeta apenas os usuários do Windows 2000.

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, AIX, developerWorks, eServer, iSeries, MVS, POWER4, POWER5+, PowerPC, pSeries, System i, System p, System z, WebSphere, System z9, z/OS 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.

Microsoft, Windows e o logotipo do Windows são marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.

Linux é uma marca registrada de 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.