Nota: Antes de utilizar estas informações e o produto que elas suportam, certifique-se de ler as informações gerais em Avisos.
Esta edição do Guia do Usuário aplica-se ao IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 e a todos os releases, modificações e Atualizações de Serviços subseqüentes, até que seja indicado de outra maneira em novas edições.
(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Todos os direitos reservados.
(c) Copyright International Business Machines Corporation, 1999, 2005. Todos os direitos reservados.
Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corporation.
Este Guia do Usuário oferece informações gerais sobre o IBM(R) 32-bit SDK and Runtime Environment for Windows(R), Java(TM) 2 Technology Edition, Version 5.0 e informações específicas sobre as diferenças da implementação da IBM comparadas com a implementação da Sun. Leia este Guia do Usuário juntamente com a documentação mais extensa encontrada no Web site da Sun: http://java.sun.com.
O SDK e o Runtime Environment são suportados nos seguintes produtos:
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.
As alterações técnicas deste Guia do Usuário para a Versão 5.0, com exceção das alterações menores ou evidentes, como a atualização de "1.4.2" para "5.0", estão indicadas em vermelho ao visualizar em HTML ou em uma cópia impressa colorida e por barras verticais à esquerda das alterações.
Os termos "Runtime Environment" e "Java Virtual Machine" são utilizados alternadamente neste Guia do Usuário.
O IBM SDK é um ambiente de desenvolvimento para gravação e execução de applets e aplicativos compatíveis com o IBM Java 5.0 Core Application Program Interface (API).
O SDK inclui o Runtime Environment para 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 que incluem os arquivos de classe. O Runtime Environment contém apenas um subconjunto das classes localizadas no SDK e permite suportar um program Java no tempo de execução, mas não permite compilar programas Java. O Runtime Environment para Windows não inclui nenhuma das ferramentas de desenvolvimento, como appletviewer.exe, o compilador Java (javac.exe) ou as classes que pertençam apenas aos sistemas de desenvolvimento.
Além das plataformas o pacote Java Communications API (Application Programming Interface) é fornecido para utilização com o Runtime Environment para Windows. Informações sobre ele podem ser encontradas em Utilizando o Java Communications API (JavaComm).
Em geral, qualquer applet ou aplicativo que seja executado com uma versão anterior do SDK deverá ser executado corretamente com o IBM 32-bit SDK for Windows, v5.0. Não há garantia de que as classes compiladas com esta versão funcionem com as versões anteriores.
|O IBM 32-bit SDK for Windows, V5.0, |foi criado com o Microsoft Visual Studio .NET 2003.
Para ler a documentação da Sun sobre compatibilidade, consulte o Web site da Sun em http://java.sun.com.
Se você estiver fazendo upgrade do SDK de um release anterior, faça backup de todos os arquivos de configuração e arquivos de política de segurança antes de continuar com o upgrade.
Depois do upgrade, pode ser necessário restaurar ou reconfigurar esses arquivos porque o processo de upgrade pode tê-los excluídos. Verifique a sintaxe dos novos arquivos antes de restaurar os arquivos originais porque o formato ou opções de tais arquivos podem ter sido alteradas.
Na Versão 5.0, o IBM Runtime Environment para Windows contém novas versões do IBM Java Virtual Machine e do compilador JIT (Just-In-Time). Se você estiver migrando de um IBM Runtime Environment mais antigo, observe que:
O SDK contém várias ferramentas de desenvolvimento e um JRE (Java Runtime Environment). Esta seção descreve o conteúdo das ferramentas do SDK e o Runtime Environment.
Os aplicativos escritos totalmente em Java não devem ter dependências na estrutura de diretório do IBM SDK (ou arquivos desses diretórios). Qualquer dependência na estrutura de diretório do SDK (ou os arquivos desses diretórios) poderiam resultar em problemas de portabilidade do aplicativo. Os aplicativos do JNI (Java Native Interface) terão algumas dependências menores.
Nota: os Guias do Usuário e Javadoc, e as licenças, arquivos de direitos autorais e diretório demo acompanhantes, são a única documentação incluída nesse SDK para Windows. No Web site da Sun, é possível tanto visualizar quanto fazer download do pacote de documentação de software da Sun: http://java.sun.com.
Para instalar o pacote SDK ou Runtime Environment, faça download do pacote de instalação pertinente. Certifique-se de fazer o download de todos os pacotes para o mesmo diretório. Os pacotes e seus nomes de arquivo são listados em Instalação (Interativa) Assistida; 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.
Os pacotes que você pode instalar são:
Outros pacotes são fornecidos como arquivos zip:
O Runtime Environment é instalado por padrão no diretório C:\Arquivos de Programas\IBM\Java50\jre.
Se você fizer download do pacote SDK instalável, poderá optar por instalar:
É possível instalar os componentes individualmente ou em combinações.
No assistente de instalação, são apresentadas as seguintes opções:
Durante a instalação do 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ê o instalar como a JVM do sistema, o programa de instalação copia os arquivos java.exe e javaw.exe no diretório do sistema Windows. Se existir atualmente uma versão do java.exe ou javaw.exe no diretório do sistema Windows, será solicitado que você substitua a versão existente pela versão atual. A instalação destes arquivos no diretório do sistema Windows torna esse Runtime Environment a JVM padrão do sistema. Além disso, a chave de registro "Current Version" é definida para corresponder a esta instalação.
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-java2-sdk-50-win-i386 /r
ou
ibm-java2-jre-50-win-i386 /r
Dependendo de seu produto Windows, um arquivo de resposta (setup.iss) é criado no diretório C:\Windows ou C:\Winnt, em que C: é a unidade de inicialização.
A seguinte mensagem poderá ser exibida durante uma instalação interativa:
Outro Java Runtime Environment está atualmente instalado como o System JVM. Selecione Sim para substituir esta versão ou Não para sair desta instalação.
Se esta mensagem for exibida, selecione Não e saia da instalação. Vá para o diretório do sistema Windows e exclua os seguintes dois arquivos:
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-java2-sdk-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log ibm-java2-jre-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Se a instalação for bem-sucedida, o arquivo de log conterá a cadeia ResultCode=0.
O IBM Accessibility Bridge é instalado mas, por padrão, fica desativado. Para ativar o IBM Accessibility Bridge, exclua o sinal de número do início da seguinte linha no arquivo Accessibility.properties, no diretório jre/lib:
#assistive_technologies=JawBridge
Este Web site informa sobre os Utilitários de Acessibilidade:
http://java.sun.com/products/jfc/accessibility.html
É possível desativar o suporte de Acessibilidade Java para melhorar o desempenho de carregamento dos aplicativos Java da JVM que não fornecem suporte de tecnologia assistida Java, especialmente em links da rede.
Para desativar o suporte de Acessibilidade Java, defina 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.
No Windows, um processo tem duas páginas de códigos: o página de códigos ANSI (ou Windows) e a página de códigos OEM (ou DOS).
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 comando java. 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.
Observe que, se você alterar a variável de ambiente PATH como descrito a seguir, substituirá quaisquer arquivos executáveis Java existentes em seu caminho.
Depois de instalar o SDK, você poderá executar uma ferramenta digitando seu nome em um aviso de shell com um nome de arquivo como um argumento.
É possível especificar o caminho para uma ferramenta digitando a cada vez o caminho antes do nome da ferramenta. Por exemplo, se o SDK para Windows estiver instalado em C:\Arquivos de Programas\IBM\Java50\bin, você poderá compilar um arquivo denominado myfile.java, digitando o seguinte em um prompt de comando:
"C:\Arquivos de Programas\IBM\Java50\bin\javac" myfile.java
Para evitar que o caminho completo seja digitado a cada vez:
Se você instalou o SDK ou Runtime Environment em um diretório diferente, substitua C:\Arquivos de Programas\IBM\Java50\ pelo diretório em que instalou o SDK ou Runtime Environment
javac myfile.java
A variável de ambiente PATH ativa o Windows para localizar arquivos executáveis, como javac, java e javadoc, de qualquer diretório atual. Para exibir o valor atual de seu PATH, digite o seguinte em um prompt de comandos:
echo %PATH%
O CLASSPATH informa as ferramentas do SDK, como java, javac e javadoc, onde localizar as bibliotecas da classe Java.
Será necessário definir o CLASSPATH explicitamente somente se uma das seguintes opções se aplicar:
Para exibir o valor atual do CLASSPATH, digite o seguinte em um prompt de comandos:
echo %CLASSPATH%
Se pretende desenvolver e executar aplicativos que utilizem ambientes de tempo de execução diferentes, incluindo outras versões que você tenha instalado separadamente, deverá definir o CLASSPATH (e o PATH) explicitamente para cada aplicativo. Se você pretende executar vários aplicativos simultaneamente e utilizar ambientes de tempo de execução diferentes, cada aplicativo deverá ser executado em sua própria janela de comandos.
Se você pretende executar apenas uma versão do Java por vez, poderá utilizar um script batch para alternar entre os ambientes de tempo de execução diferentes.
Para desinstalar o SDK, caso o tenha instalado utilizando a instalação assistida ou não-assistida:
Esse procedimento remove todos os pacotes que estão instalados com o Instalador. Ele não remove o pacote Java Communications API (consulte Java Communications API) ou quaisquer arquivos adicionais que foram extraídos dos pacotes zip.
Quando várias instalações entre o IBM 32-bit SDK for Windows, v5.0 e as versões V1.3.1 e anteriores são mantidas, se você desinstalar a versão anterior enquanto uma versão V5.0 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 V5.0, corrompendo, portanto, a instalação do V5.0:
Portanto, reinstale o V5.0 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.
A ferramenta java ativa um aplicativo Java iniciando um Java Runtime Environment e carregando uma classe especificada.
A JVM procura a classe inicial (e outras classes utilizadas) em três conjuntos de locais: no caminho de classe de auto-inicialização, nas extensões instaladas e no caminho de classe do usuário. Os argumentos especificados após o nome da classe ou o nome do arquivo JAR são passados para a função principal.
O comando javaw é idêntico ao java, exceto que o javaw não possui janela de console associada. Utilize javaw quando não desejar que uma janela de prompt de comandos seja exibida. O ativador javaw exibirá uma caixa de diálogo com informações sobre erros se houver falha na ativação.
Os comandos java e javaw utilizam a seguinte sintaxe:
java [ opções ] class [ argumentos ... ] java [ opções ] -jar file.jar [ argumentos ... ] javaw [ opções ] class [ argumentos ... ] javaw [ opções ] -jar file.jar [ argumentos ... ]
Os itens entre colchetes são opcionais.
Se a opção -jar for especificada, o arquivo JAR nomeado irá conter arquivos de classe e recurso para os aplicativos com a classe de inicialização indicada pelo cabeçalho do manifesto Main-Class.
O ativador possui um conjunto de opções padrão suportadas no ambiente de tempo de execução atual e que serão suportadas em releases futuros. Além disso, há um conjunto de opções fora do padrão. As opções padrão foram escolhidas para o melhor uso geral. Uma ação deve ser tomada se decidir fazer alterações.
Você pode especificar as opções do Java e as propriedades do sistema de 3 diferentes modos. São, por ordem de preferência:
As opções mais à direita na linha de comandos têm preferência em relação às mais a esquerda; por exemplo, se especificar as opções -Xint -Xjit myClass, -Xjit tem a preferência.
As opções -X listadas a seguir não são opções padrão e, portanto, estão sujeitas a alterações sem aviso prévio.
Para opções que utilizam o parâmetro <tamanho>, você deve sufixar o número com "k" ou "K" para indicar kilobytes, "m" ou "M" para indicar megabytes ou "g" ou "G" para indicar gigabytes.
Para obter o número de construção e versão IBM, em um prompt de comando command, digite:
java -version
O comando java e outros comandos do ativador java (por exemplo, javaw) permitem que um nome de classe seja especificado com qualquer caractere pertencente ao conjunto de caracteres do código de idioma atual.
Também é possível especificar qualquer caractere Unicode nos argumentos e no nome de classe utilizando seqüências de escape java. Para fazê-lo, será necessário especificar -Xargencoding. Para especificar um caractere Unicode, utilize seqüências de escape no formato \u####, em que # é um dígito hexadecimal (0 a 9, A a F).
Como alternativa, para especificar que o nome de classe e os argumentos de comando possuem a codificação UTF8, utilize -Xargencoding:utf8 ou, na codificação ISO8859_1, utilize -Xargencoding:latin.
Por exemplo, para especificar uma classe denominada "HelloWorld" utilizando a codificação Unicode para ambas as letras maiúsculas, utilize este comando:
java -Xargencoding '\u0048ello\u0057orld'
Os comandos java e javaw fornecem mensagens de saída traduzidas. Essas mensagens são diferentes com base no código do idioma em que o Java está sendo executado. As descrições detalhadas de erros e outras informações de depuração retornadas por java estão em inglês.
Para definir uma classe java ou arquivo jar para execução automática a partir do arquivo, utilize a opção Ferramentas->Opções de Pasta->Tipos 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\Java50\jre\bin\java.exe %l %*
A Sun fornece o Java Access Bridge para fornecer tecnologias auxiliares nativas do Windows, tais como leitoras de tela, acesso ao suporte de Acessibilidade Java em um aplicativo Java. Essas tecnologias auxiliares nativas do Windows devem suportar chamadas ao Java Access Bridge.
O Java Access Bridge, disponível na 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 ser utilizada com o JawBridge.
Se você já tiver ativado o IBM Accessibility Bridge (JawBridge), o qual permite que a 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 ler 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 site mostra como fazer download do Java Access Bridge:
http://java.sun.com/products/jfc/accessibility.html
O compilador IBM Just-In-Time (JIT) gera dinamicamente o código da máquina para seqüências de bytecodes utilizadas com freqüência em aplicativos e applets Java durante a execução. |O compilador JIT V5.0 |entrega novas otimizações como resultado da pesquisa do compilador, |melhora as otimizações implementadas em versões anteriores do JIT e fornece |exploração de hardware aprimorada.
O IBM SDK e o Runtime Environment incluem o JIT, que está ativado por padrão tanto nos aplicativos de usuário quanto nas ferramentas SDK. Normalmente, não há nenhuma necessidade de chamar explicitamente o JIT; a compilação do bytecode Java para o código da máquina ocorre de modo transparente. Contudo, se encontrar um problema com o Runtime Environment durante a execução de um aplicativo ou applet Java, há a possibilidade de desativar o JIT para facilitar o isolamento do problema. A desativação do JIT deve ser um medida temporária apenas; ele é necessário para um desempenho adequado.
Há três maneiras de desativar o JIT:
No prompt de comandos no qual o aplicativo está executando, digite:
set JAVA_COMPILER=NONE
É possível, também, configurar permanentemente JAVA_COMPILER, por meio da interface gráfica com o usuário. Abra o Painel de Controle, selecione Sistema e, na guia Avançadas, selecione Variáveis de Ambiente.
java -Djava.compiler=NONE MyApp
java -Xint MyApp
Ambas as opções da linha de comandos substituem a variável de ambiente JAVA_COMPILER.
Para ativar o JIT explicitamente, configure a variável de ambiente JAVA_COMPILER como "jitc" ou utilize a opção -D para configurar a propriedade java.compiler como "jitc". Como alternativa, utilize a opção -Xjit (e omita a opção -Xint) na linha de comandos da JVM para ativar o JIT.
Se a variável de ambiente JAVA_COMPILER ou a propriedade java.compiler estiver definida para "" (cadeia vazia), o JIT permanecerá desativado. Para remover a configuração da variável de ambiente apropriadamente, digite set JAVA_COMPILER= no prompt de comandos.
Para determinar se o JIT está ativado, digite o seguinte no prompt de comandos:
java -version
Se o JIT não estiver sendo utilizado, será exibida uma mensagem que inclui o seguinte:
(JIT disabled)
Se o JIT estiver sendo utilizado, será exibida uma mensagem que inclui o seguinte:
(JIT ativado)
Para obter mais informações sobre o JIT, consulte o Manual de Diagnóstico.
O Coletor de Lixo gerencia a memória utilizada pelo Java e pelos aplicativos em execução na VM.
Quando o Coletor de Lixo recebe um pedido para armazenamento, a memória não utilizada no heap será colocada à parte - "allocation". O Coletor de Lixo também procura por áreas de memória que não são mais referenciadas e libera-as para reutilização - "collection".
A fase de coleta pode ser acionada por um falha na alocação de memória, que ocorre quando não é deixado espaço para um pedido de armazenamento ou por uma chamada System.gc() explícita.
A coleta de lixo pode afetar significativamente o desempenho do aplicativo; portanto, o IBM Virtual Machine oferece vários métodos de otimizar a forma com que a coleta de lixo é executada, reduzindo, dessa forma, o efeito no aplicativo.
Para obter informações mais detalhadas sobre a coleta de lixo, consulte o Manual de Diagnóstico.
A opção -Xgcpolicy especifica a política de coleta de lixo.
-Xgcpolicy utiliza os valores optthruput (o padrão e o valor recomendado), optavgpause ou gencon. A opção controla o comportamento do coletor de lixo, fazendo trocas entre o throughput do aplicativo e o sistema geral, e faz com que os tempos de pausa sejam causados pela coleta de lixo.
O formato da opção e seus valores são:
-Xgcpolicy:optthruput
-Xgcpolicy:optavgpause
-Xgcpolicy:gencon
Quando a tentativa de um aplicativo em criar um objeto não pode ser atendida imediatamente no espaço disponível no heap, o coletor de lixo é responsável pela identificação de objetos não referidos (lixo), por excluí-los e retornar o heap para um estado no qual pedidos de alocação imediatos e subseqüentes possam ser atendidos rapidamente. Tais ciclos de coleta de lixo introduzem pausas inesperadas ocasionais na execução do código do aplicativo. Como os aplicativos aumentam de tamanho e complexidade e os heaps tornam-se correspondentemente maiores, esse tempo de pausa da coleta de lixo tende a aumentar de tamanho e importância. O valor padrão da coleta de lixo, -Xgcpolicy:optthruput, fornece um rendimento alto para aplicativos, mas com o custo das pausas ocasionais, que podem variar de alguns milissegundos até vários segundos, dependendo do tamanho do heap e da quantidade de lixo.
A JVM utiliza duas técnicas para reduzir tempos de pausa:
A opção de linha de comandos -Xgcpolicy:optavgpause solicita o uso da coleta de lixo simultânea para reduzir significativamente o tempo gasto em pausas para coletas de lixo. A Coleta de Lixo Simultânea reduz o tempo de pausa executando algumas atividades de coleta de lixo simultaneamente à execução normal de programas para minimizar a interrupção causada pela coleta do heap. A opção -Xgcpolicy:optavgpause também limita o efeito do aumento do tamanho de heap durante a pausa para coleta de lixo. A opção -Xgcpolicy:optavgpause é mais útil para configurações que apresentam grandes heaps. Com o tempo de pausa reduzido, você poderá perceber uma certa redução no rendimento do processamento dos aplicativos.
Durante a coleta de lixo simultânea, um tempo significativo é gasto com a identificação de objetos relativamente resistentes que não conseguem ser coletados. Se a Coleta de Lixo concentrar-se apenas nos objetos com a maior tendência de serem recicláveis, será possível reduzir ainda mais os tempos de pausa de alguns aplicativos. A Coleta de Lixo com Base em Gerações obtém o mesmo resultado dividindo o heap em duas "gerações", as áreas de "desenvolvimento" e "estabilidade". Os objetos são colocados em uma dessas áreas dependendo da duração. A área de desenvolvimento é a menor e contém objetos mais recentes, enquanto a área de estabilidade é maior e contém objetos mais antigos. Os objetos são alocados primeiro à área de desenvolvimento; se persistirem por um período suficiente, avançarão em algum momento para a área de estabilidade.
A Coleta de Lixo com Base em Gerações depende da curta duração da maioria dos objetos. Ela reduz os tempos de pausa concentrando-se na tentativa de reivindicar o armazenamento na área de desenvolvimento, pois essa área inclui a maioria do espaço reciclável. Em vez de tempos de pausa ocasionais, mas demorados, para coletar todo o heap, a área de desenvolvimento é coletada com mais freqüência e, se essa área for pequena o bastante, os tempos de pausa serão relativamente menores. Entretanto, a Coleta de Lixo com Base em Gerações apresenta a desvantagem da possibilidade de que, com o passar do tempo, a área de estabilidade fique lotada se vários objetos persistirem por muito tempo. Para minimizar o tempo de pausa quando essa situação ocorrer, utilize uma combinação da Coleta de Lixo Simultânea com a Coleta de Lixo com Base em Gerações. A opção -Xgcpolicy:gencon solicita o uso combinado dessas duas técnicas para ajudar a minimizar o tempo gasto com qualquer pausa para coleta de lixo.
Se o heap Java estiver quase cheio, e houver pouco lixo para ser recuperado, os pedidos de novos objetos poderão não ser atendidos rapidamente por não haver espaço disponível de imediato. Se o heap for operado com capacidade quase cheia, o desempenho do aplicativo poderá ser afetado, independentemente de quais opções anteriores forem utilizadas; e, se os pedidos de mais espaço para o heap continuarem a ser feitos, o aplicativo receberá uma exceção OutofMemory, o que resultará na finalização da JVM caso a exceção não seja capturada e tratada. Nesse ponto, a JVM produz um arquivo de diagnósticos "javadump". Nessas condições, recomenda-se aumentar o tamanho do heap utilizando a opção -Xmx ou reduzir o número de objetos do aplicativo em uso. Para obter mais informações, consulte Manual de Diagnóstico.
Quando surge um sinal que é do interesse da JVM, uma rotina de tratamento de sinais é chamada. Essa rotina de tratamento de sinais determina se o sinal foi chamado por causa de um encadeamento Java ou não-Java.
Se o sinal for por causa de um encadeamento Java, a JVM assumirá o controle do tratamento do sinal. Se uma rotina de tratamento de aplicativo para esse sinal for instalada e você não tiver especificado a opção de linha de comandos -Xnosigchain, após o término do processamento da JVM, essa rotina de tratamento será chamada.
Se o sinal for por causa de um encadeamento não-Java e o aplicativo que instalou a JVM tiver instalado anteriormente sua própria rotina de tratamento para o sinal, o controle será fornecido a essa rotina de tratamento. Caso contrário, se o sinal for solicitado pela JVM ou pelo aplicativo Java, ele será ignorado ou a ação padrão será executada.
A exceção a essa regra está no Windows, em que para um sinal gerado externamente (por exemplo, quando você pressiona CTRL-BREAK) um novo encadeamento é criado para executar a rotina de tratamento 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:
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:
O encerramento é idêntico ao encerramento iniciado por uma chamada para o método System.exit().
Outros sinais utilizados pela JVM destinam-se a propósitos de controle interno e não causam a sua terminação. O único sinal de controle de interesse é SIGBREAK, o que faz com que um Javadump seja gerado.
A Tabela 1 a seguir mostra os sinais utilizados pela JVM. Os sinais são agrupados na tabela por tipo ou uso, como se segue:
| Nome do Sinal | Tipo de Sinal | Descrição | Desativado pelo -Xrs |
|---|---|---|---|
| SIGINT | Interrupção | Atenção interativa (CTRL-C). A JVM sai normalmente. | Sim |
| SIGTERM | Interrupção | Pedido de finalização. A JVM sairá normalmente. | Sim |
| SIGBREAK | Controle | Um sinal de pausa proveniente de um terminal. A JVM utiliza isso para efetuar Javadumps. | Sim |
Utilize a opção -Xrs (reduz uso de sinais) para evitar que a JVM manipule a maior parte dos sinais. Para obter informações adicionais, consulte a página do ativador de aplicativos Java da Sun em http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.
Os sinais 2 (SIGINT) e 15 (SIGTERM) nos encadeamentos da JVM fazem com que ela seja encerrada. Assim, uma rotina de tratamento de sinais de aplicativo não deve tentar uma recuperação desse sinal a menos que a JVM não seja mais necessária.
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.
Para utilizar jsig.dll, efetue o link com o aplicativo que cria ou incorpora uma JVM.
O IBM SDK contém o processador XSLT4J e o analisador XML4J que estão em conformidade com a especificação do JAXP 1.3. Essas ferramentas permitem que você analise e transforme documentos XML, independentemente de qualquer implementação de processamento XML específico. Ao utilizar "Factory Finders" para localizar as implementações SAXParserFactory, DocumentBuilderFactory e TransformerFactory, seu aplicativo poderá alternar entre diferentes implementações sem precisar alterar qualquer código.
|A tecnologia XML incluída com o IBM SDK é semelhante ao |Apache Xerces Java e Apache Xalan Java. Consulte | http://xml.apache.org/xerces2-j/ e |http://xml.apache.org/xalan-j/ para obter |mais informações.
O processador XSLT4J permite que você escolha entre o processador Interpretativo XSLT original ou o novo processador de Compilação XSLT. O processador Interpretativo foi projetado para aprimorar e depurar ambientes. Ele suporta as funções de extensão XSLT não suportadas pelo processador de Compilação XSLT. O processador de Compilação XSLT foi projetado para ambientes de tempo de execução de alto desempenho; ele gera um mecanismo de transformação, ou translet, de uma folha de estilo XSL. Essa abordagem separa a interpretação das instruções da folha de estilo de seu aplicativo de tempo de execução para dados XML.
O processador Interpretativo XSLT é o processador padrão. Para selecionar o processador de Compilação XSLT você pode:
Para implementar propriedades no arquivo jaxp.properties, copie jaxp.properties.sample para jaxp.properties em C:\Arquivos de Programas\IBM\Java50\. Esse arquivo também contém detalhes completos sobre o procedimento utilizado para determinar as implementações que serão utilizadas para o TransformerFactory, o SAXParserFactory e o DocumentBuilderFactory.
Para melhorar o desempenho ao transformar um objeto StreamSource com um processador de Compilação XSLT, especifique a classe com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager como o fornecedor do serviço org.apache.xalan.xsltc.dom.XSLTCDTMManager. Para determinar o fornecedor de serviços, tente cada uma das etapas até localizar org.apache.xalan.xsltc.dom.XSLTCDTMManager:
O processador de Compilação XSLT detecta o fornecedor de serviços para o serviço org.apache.xalan.xsltc.dom.XSLTCDTMManager quando um objeto javax.xml.transform.TransformerFactory é criado. Quaisquer objetos javax.xml.transform.Transformer ou javax.xml.transform.sax.TransformerHandler criados utilizando esse objeto TransformerFactory utilizarão o mesmo fornecedor de serviços. Os fornecedores de serviços só podem ser alterados modificando uma das configurações descritas acima e depois criando um novo objeto TransformerFactory.
Se você estiver utilizando uma versão mais antiga do Tomcat, essa limitação poderá existir.
Se você estiver utilizando uma versão mais antiga do Xerces (anterior a 2.0) ou Xalan (anterior a 2.3) na substituição confirmada, poderá obter uma exceção de ponteiro nulo quando ativar o aplicativo. Essa exceção ocorre porque essas versões mais antigas não manipulam o arquivo jaxp.properties corretamente.
Para evitar essa situação, utilize uma das seguintes soluções alternativas:
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory= org.apache.xerces.jaxp.SAXParserFactoryImplou
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory= org.apache.xerces.jaxp.DocumentBuilderFactoryImplou
set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory= org.apache.xalan.processor.TransformerFactoryImpl
As seções a seguir fornecem informações sobre como utilizar o SDK para Windows para desenvolver aplicativos Java. Consulte Ferramentas do SDK para obter detalhes sobre as ferramentas disponíveis.
Para depurar os programas Java, utilize o aplicativo JDB (Java Debugger) ou outros depuradores que comunicam utilizando o JPDA (Java Platform Debugger Architecture) fornecido pelo SDK para Windows.
O JDB (Java Debugger) é incluído no SDK para Windows. O depurador é chamado pelo comando jdb; ele "conecta-se" à JVM utilizando o JPDA. Para depurar um aplicativo Java:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port>
MyApp <MyApp args>jdb -attach <número da porta>O depurador será conectado à JVM e você, agora, poderá emitir uma série de comandos para examinar e controlar o aplicativo Java; por exemplo, digite run para permitir a execução do aplicativo Java.
Para obter mais informações sobre as opções do JDB, digite:
jdb -help
Para obter mais informações sobre os comandos do JDB:
O JDB também pode ser utilizado para depurar aplicativos JDB em JPDA de máquinas remotas que utilizem um soquete TCP/IP para se conectar à JVM remota.
jdb -attach <nome da máquina ou endereço ip>:<número da porta>
Ao ativar uma sessão de depuração utilizando o transporte dt_socket, verifique se as portas especificadas estão livres para utilização.
|A JVMDI (Java Virtual Machine Debugging Interface) |não é suportada neste release. Ela foi substituída pela JVMTI (Java |Virtual Machine Tool Interface).
Para obter mais informações sobre o JDB e o JPDA e seu uso, consulte estes Web sites:
Alguns aplicativos Java devem ser capazes de determinar se estão sendo executados em uma JVM de 32 ou de 64 bits. Por exemplo, se o aplicativo tiver uma biblioteca de códigos nativos, ela deverá ser compilada separadamente nos formatos 32 e 64 bits das plataformas que suportam ambos os modos de operação, 32 e 64 bits. Nesse caso, seu aplicativo deverá carregar a biblioteca correta no tempo de execução, pois não será possível misturar código de 32 e 64 bits.
A propriedade de sistema com.ibm.vm.bitmode permite que os aplicativos determinem o modo em que a JVM está executando. Ela retorna os seguintes valores:
Você pode verificar o com.ibm.vm.bitmode a partir do código do aplicativo utilizando a chamada:
System.getProperty("com.ibm.vm.bitmode");
Os números de versão válidos do JNI que os programas nativos podem especificar na chamada de API JNI_CreateJavaVM() são:
Esse número de versão determina somente o nível da interface nativa do JNI a ser utilizada. O nível real da JVM criado é especificado pelas bibliotecas J2SE (isto é, v5.0). A API da interface do JNI não afeta a especificação de idioma implementada pela JVM, as APIs da biblioteca de classes ou qualquer outra área do comportamento da JVM. Para obter informações adicionais, consulte http://java.sun.com/j2se/1.5.0/docs/guide/jni.
Se seu aplicativo precisar de duas bibliotecas do JNI, uma criada para 32 bits e outra para 64 bits, utilize a propriedade do sistema com.ibm.vm.bitmode para determinar se está executando com um JVM de 32 bits ou 64 bits e escolha a biblioteca de propriedades.
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.
Para executar um applet com o Applet Viewer, digite o seguinte em um prompt de shell:
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 shell:
appletviewer <demo>\GraphLayout\example1.html
em que <demo> é substituído pelo caminho completo onde você descompactou o pacote demo.
Por exemplo, http://java.sun.com/applets/NervousText/example1.html é a URL de uma página da Web que chama um applet. Para chamar o Applet Viewer nessa página da Web, digite em um prompt shell:
appletviewer http://java.sun.com/applets/NervousText/example1.html
O Applet Viewer não reconhece a opção charset da tag <META>. Se o arquivo que o appletviewer carregar não for codificado como o padrão do sistema, poderá ocorrer uma exceção de E/S. Para evitar a exceção, utilize a opção -encoding ao executar o appletviewer. Exemplo:
appletviewer -encoding JISAutoDetect sample.html
É possível depurar applets utilizando a opção -debug do Applet Viewer. Ao depurar applets, será recomendado que você chame o Applet Viewer do diretório que contém o arquivo HTML que chama o applet. Exemplo:
cd <demo>\TicTacToe appletviewer -debug example1.html
Onde <demo> é substituído pelo caminho completo onde você descompactou o pacote demo.
A documentação sobre como depurar applets utilizando o Applet Viewer pode ser localizada no Web site da Sun: http://java.sun.com.
| | |É possível ativar o suporte a páginas grandes, nos sistemas com suporte |para tal, iniciando o Java com a opção -Xlp.
|O uso da página grande é pretendido principalmente para fornecer melhorias de desempenho |para aplicativos que aloquem muita memória e freqüentemente acessem essa memória. |As melhorias de desempenho de página grande são ocasionadas principalmente pelo número reduzido |de falhas no TLB (Translation Lookaside Buffer). Os TLB mapeia um intervalo maior |de memória virtual e, portanto, causa esse aprimoramento.
|Para que a JVM utilize páginas grandes, seu sistema deverá ter um número adequado |de páginas grandes contíguas disponíveis. Se, mesmo quando há paginas |suficientes disponíveis, não foi possível alocar páginas grandes, |possivelmente as páginas grandes não são contíguas.
|Alocações grandes de página obterão êxito somente se a política |administrativa local do usuário JVM estiver configurada para permitir |"Lock pages in memory".
O Java 2 Platform, Standard Edition (J2SE) suporta, pelo menos, as especificações definidas em Official Specifications for CORBA support in J2SE (V1.5). Em alguns casos, o IBM J2SE ORB suporta as versões mais recentes das especificações.
Este SDK suporta todas as versões de GIOP, como definido nos capítulos 13 e 15 da especificação do CORBA 2.3.1, documento OMG formal/99-10-07, o qual pode ser obtido em:
http://www.omg.org/cgi-bin/doc?formal/99-10-07
O GIOP bidirecional não é suportado.
Este SDK suporta Interceptadores Portáteis, como definido pelo OMG no documento ptc/01-03-04, o qual pode ser obtido em:
http://www.omg.org/cgi-bin/doc?ptc/01-03-04
Os Interceptadores Portáteis são ganchos para o ORB por meio dos quais os serviços ORB podem interceptar o fluxo normal de execução do ORB.
Este SDK suporta o Serviço de Nomes Interoperável, como definido pelo OMG no documento ptc/00-08-07, o qual pode ser obtido em:
http://www.omg.org/cgi-bin/doc?ptc/00-08-07
A porta padrão utilizada pelo Servidor de Nomes Transientes (o comando tnameserv), quando nenhum parâmetro ORBInitialPort é fornecido, foi alterada de 900 para 2809, que é o número da porta registrado no IANA (Internet Assigned Number Authority) para um Serviço de Nomes do CORBA. Os programas que dependem desse padrão podem precisar ser atualizados para funcionarem com esta versão.
O contexto inicial retornado do Servidor de Nomes Transientes agora é org.omg.CosNaming.NamingContextExt. Os programas existentes que reduzem a referência a um contexto org.omg.CosNaming.NamingContext ainda funcionam e não precisam ser recompilados.
O ORB suporta os parâmetros -ORBInitRef e -ORBDefaultInitRef que são definidos pela especificação do Serviço de Nomes Interoperável; a operação ORB::string_to_object agora suporta os formatos de cadeia ObjectURL (corbaloc: e corbaname:) que são definidos pela especificação do Serviço de Nomes Interoperável.
O OMG especifica um método ORB::register_initial_reference para registrar um serviço no Serviço de Nomes Interoperável. No entanto, esse método não está disponível na API do Sun Java Core em Versão 5.0. Os programas que precisam registrar um serviço na versão atual devem chamar esse método na classe de implementação do ORB interno da IBM. Por exemplo, para registrar um serviço "MyService":
((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MyService",
serviceRef);
em que orb é uma instância de org.omg.CORBA.ORB, retornada de ORB.init() , e serviceRef é um objeto CORBA, conectado ao ORB. Esse é um mecanismo intermediário, e não é compatível com versões futuras ou portáteis para ORBs não-IBM.
Um recurso de depuração de tempo de execução fornece capacidade de utilização aprimorada. Você pode considerá-lo útil para diagnóstico de problemas ou ele pode ser solicitado pela equipe de serviços da IBM. O rastreio é controlado por três propriedades de sistema.
Por exemplo, para rastrear eventos e mensagens GIOP formatadas, digite:
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true myapp
Não ative o rastreio para operação normal, pois ele pode causar degradação no desempenho. Mesmo que você tenha desativado o rastreio, o FFDC (First Failure Data Capture) ainda funciona, de forma que apenas os erros sérios sejam relatados. Se um arquivo de saída de depuração for gerado, examine-o para analisar o problema. Por exemplo, o servidor pode ter parado sem executar um ORB.shutdown().
O conteúdo e o formato da saída de rastreio variam de acordo com a versão.
As seguintes propriedades ajudam você a ajustar o ORB:
Por exemplo, para definir o tamanho do fragmento para 4096 bytes:
java -Dcom.ibm.CORBA.FragmentSize=4096 myapp
O tamanho padrão do fragmento é 1024 bytes. Você pode desativar a fragmentação definindo o tamanho do fragmento como 0.
java -Dcom.ibm.CORBA.RequestTimeout=30
-Dcom.ibm.CORBA.LocateRequestTimeout=30 myapp
Por padrão, o ORB aguarda indefinidamente por uma resposta. Para impedir que as conexões sejam encerradas desnecessariamente, não defina um valor muito baixo para o tempo limite.
Por exemplo, para que o ORB utilize a porta 1050, digite:
java -Dcom.ibm.CORBA.ListenerPort=1050 myapp
Se essa propriedade for definida, o ORB começará a atender assim que for inicializado. Caso contrário, ele começará a atender somente quando for solicitado.
Ao executar um Java 2 SecurityManager, a chamada de alguns métodos nas classes de API do CORBA pode fazer com que seja feita verificações de permissões, o que pode resultar em um SecurityException. Os métodos afetados incluem o seguinte:
| Classe/Interface | Método | Permissão Necessária |
|---|---|---|
|
org.omg.CORBA.ORB |
init |
java.net.SocketPermission resolve |
|
org.omg.CORBA.ORB |
connect |
java.net.SocketPermission listen |
|
org.omg.CORBA.ORB |
resolve_initial_references |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_is_a |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_non_existent |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
OutputStream _request (String, boolean) |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_get_interface_def |
java.net.SocketPermission connect |
|
org.omg.CORBA. Pedido |
invoke |
java.net.SocketPermission connect |
|
org.omg.CORBA. Pedido |
send_deferred |
java.net.SocketPermission connect |
|
org.omg.CORBA. Pedido |
send_oneway |
java.net.SocketPermission connect |
|
javax.rmi. PortableRemoteObject |
narrow |
java.net.SocketPermission connect |
Se seu programa utilizar qualquer um desses métodos, assegure-se de que ele tenha as permissões necessárias.
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.
O Java RMI (Remote Method Invocation) fornece um mecanismo simples para executar a programação Java distribuída. O RMI sobre IIOP (RMI-IIOP) utiliza o protocolo IIOP (Internet Inter-ORB) padrão do CORBA (Common Object Request Broker Architecture) para estender o Java RMI base para executar a comunicação. Isso permite direcionar a interação com quaisquer outros ORBs (Object Request Brokers) do CORBA, independentemente de terem sido implementados no Java ou em outra linguagem de programação.
A seguinte documentação está disponível:
O conjunto de encadeamento para as Rotinas de Tratamento de Conexão do RMI não é ativado por padrão.
Para ativar o conjunto de conexão implementado no nível TCPTransport do RMI, defina a opção
-Dsun.rmi.transport.tcp.connectionPool=true (ou qualquer valor que não seja nulo)
Essa versão do Runtime Environment não possui nenhuma definição que você possa utilizar para limitar o número de encadeamentos no conjunto de conexão.
Para obter informações adicionais, consulte o site do Java da Sun: http://java.sun.com.
O IBM SDK inclui suporte ao BiDirectional avançado. Para obter mais informações, consulte http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html.O Javadoc para o pacote BiDirectional é fornecido com o SDK no arquivo docs/apidoc.zip.
No Java 5.0, a classe IBM BigDecimal foi adotada pela Sun como java.math.BigDecimal. | A IBM não mantém mais o com.ibm.math.BigDecimal e está sinalizado como desaprovado. | Recomenda-se migrar o código Java existente para utilizar o java.math.BigDecimal.
|O novo java.math.BigDecimal utiliza os mesmos métodos que o |java.math.BigDecimal e o com.ibm.math.BigDecimal anteriores. O código existente que utiliza o java.math.BigDecimal |continua funcionando corretamente.
|Para migrar o código Java existente para utilizar a classe java.math.BigDecimal, altere |a instrução de importação no início do arquivo java de: importar com.ibm.math.*; para importar java.math,*;.
O IBM SDK and Runtime Environment define o Euro como a moeda padrão para os países da EMU (União Monetária Européia) para datas em ou após 1º de janeiro de 2002.
Para utilizar a moeda nacional antiga, especifique -Duser.variant=PREEURO na linha de comandos Java.
Se você estiver executando os códigos do idioma inglês (Reino Unido), dinamarquês ou suéco e desejar utilizar o Euro, especifique -Duser.variant=EURO na linha de comandos Java.
O pacote do Java Communications API (Application Programming Interface) (JavaComm) é um pacote opcional fornecido para ser utilizado com o Runtime Environment para Windows. Instale o JavaComm independentemente do SDK ou Runtime Environment.
O JavaComm API fornece aos aplicativos Java uma forma independente de plataforma de executar comunicações das portas seriais e paralelas para tecnologias como correio de voz, fax e cartões inteligentes. Depois de gravar as comunicações das portas seriais e paralelas para seus aplicativos, inclua esses arquivos em seu aplicativo.
O Java Communications API suporta as portas seriais Electronic Industries Association (EIA)-232 (RS232) e as portas paralelas Institute of Electrical and Electronics Engineers (IEEE) 1284; ela é suportada em sistemas que tenham o Runtime Environment da IBM, Versão 5.0.
Utilizando o Java Communications API, você pode:
Você precisa certificar-se de que uma cópia do SDK ou Runtime Environment esteja instalada antes de instalar o Java Communications API.
Para instalar o Java Communications API de um arquivo zip :
Se você aceitou o diretório padrão quando instalou o Runtime Environment, o arquivo comm.jar está em C:\Arquivos de Programas\IBM\Java50\jre\lib\ext.
Se o arquivo for descompactado em outro diretório, os arquivos serão colocados na mesma estrutura de diretório; porém C:\Arquivos de Programas\IBM\Java50\ é substituído pelo diretório onde você descompactou o arquivo.
Depois de instalar o Java Communications API, é necessário:
Ao imprimir com o Java Communications API, poderá ser necessário pressionar "Avanço do Papel", "Continuar" ou similar na impressora.
Para desinstalar o Java Communications API, 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\Java50\.
A documentação da API e as amostras do Java Communications API podem ser localizadas no Web site da Sun: http://java.sun.com.
O Plug-in Java é um plug-in de navegador da Web. Ao utilizar o Java Plug-in, você pode ignorar a JVM padrão de seu navegador da Web e utilizar um Runtime Environment de sua preferência para executar os applets ou beans no navegador.
É necessário permitir o término do carregamento dos applets para evitar que o navegador seja 'interrompido'. Por exemplo, se você utilizar o botão Voltar e depois o botão Avançar enquanto um applet estiver sendo carregado, pode ser que as páginas HTML não sejam carregadas.
O Java Plug-in é documentado pela Sun em: http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.
|
| |Sistema Operacional | |Internet Explorer | |Netscape | |Mozilla |
|---|---|---|---|
| | Windows 2000 | |5.5 SP2, 6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
| |Windows XP | |6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
| |Windows Server 2003 | |6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
Observe que o Internet Explorer 5.01, o navegador padrão do Windows 2000, |não é suportado.
Por causa das limitações em determinados navegadores, você talvez não consiga implementar todas as funções do pacote org.w3c.dom.html.
O Java Plug-in suporta caracteres de byte duplo (por exemplo, chinês tradicional BIG-5, coreano, japonês) como parâmetros para as marcações <APPLET>, <OBJECT> e <EMBED>. Será necessário selecionar a codificação de caractere correta para seu documento HTML, para que o Plug-in Java possa analisar o parâmetro. Especifique a codificação de caracteres para o documento HTML utilizando a marcação <META> na seção <HEAD> desta forma:
<meta http-equiv="Content-Type" content="text/html; charset=big5">
Esse exemplo pede que o navegador utilize a codificação de caracteres Chinese BIG-5 para analisar a utilização do arquivo HTML. Todos os parâmetros são aprovados para o Plug-in Java corretamente. No entanto, algumas das versões mais antigas dos navegadores podem não interpretar essa marcação corretamente. Nesse caso, você poderá fazer com que o navegador ignore essa marcação, mas poderá ter de alterar a codificação manualmente.
Você poderá especificar qual codificação você deseja utilizar para analisar o arquivo HTML:
Você pode utilizar o Java Web Start para implementar os aplicativos Java. O Web Start permite que o usuário ative e gerencie aplicativos diretamente da Web. Com o Java Web Start, você pode iniciar aplicativos facilmente da Web, certo de que esteja executando a versão mais recente, eliminando procedimentos de instalação ou upgrade. O Java Web Start elimina a necessidade de fazer download e instalar software, ignorando as opções de instalação demoradas.
|Além do java-vm-args documentado em http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources, o Web Start suporta -Xgcpolicy para definir a política de |coleta de lixo.
Para obter informações sobre os navegadores que suportam o Web Start, consulte Navegadores Suportados.
Para obter mais informações sobre o Web Start, consulte: http://java.sun.com/products/javawebstart e http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Para obter mais informações sobre os aplicativo de implementação, consulte: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.
Você pode chamar o Web Start de três maneiras:
Depois de fazer download do aplicativo, ele será armazenado no Java Application Cache. Se o aplicativo for acessado novamente, o Java Web Start fará download de uma versão mais recente do aplicativo, se estiver disponível, e utilizará a versão em cache, se não estiver disponível.
Se ocorrer um erro em um arquivo .jnlp (como um nome de tag inválido), o Web Start falhará sem exibir uma mensagem de erro.
Um aplicativo Java, ao contrário de um applet Java, não pode contar com um navegador da Web para serviços de instalação e tempo de execução. Quando você envia um aplicativo Java, o pacote de software provavelmente consiste nas seguintes partes:
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 do software SDK para Windows não permite que você redistribua qualquer um dos arquivos do SDK com seu aplicativo. Você precisa assegurar-se de que uma versão licenciada do SDK para Windows esteja instalada na máquina de destino.
| | |O IBM Virtual Machine (VM) permite compartilhar classes de auto-inicialização e |aplicativos entre VMs, armazenando-as em um cache na memória compartilhada. O compartilhamento de classes |reduz o consumo geral de memória virtual quando mais de uma VM compartilha |um cache. O compartilhamento de classe também reduz o tempo de inicialização de uma VM depois do cache |ter sido criado. O cache de classe compartilhada é independente de qualquer VM ativo |e persiste além do período de existência da VM que iniciou o cache.
| |O IBM SDK permite compartilhar tantas classes quanto possível, atuando |de forma transparente ao usuário.
| |O cache de classe compartilhada contém dados e metadados da classe estática de leitura |que descreve as classes. Qualquer VM pode ler ou atualizar o cache. Os VMs que |estão sendo compartilhados devem estar no mesmo release. Você deve tomar |cuidado se o bytecode do tempo de execução estiver sendo utilizado. (Consulte Modificação do Bytecode de Tempo de Execução).
| |Como o cache de classe compartilhada persiste além do período de existência de qualquer VM, |o cache é atualizado dinamicamente para refletir quaisquer modificações que possam ter sido |feitas nos JARs ou nas classes, no sistema de arquivos. A atualização dinâmica torna |o cache transparente para o aplicativo que está utilizando-o.
| |Ative o compartilhamento de classes utilizando a opção -Xshareclasses |ao iniciar uma VM, para fazer com que a VM se conecte a um cache existente ou crie |um se ainda não existir. Todas as classes de auto-inicialização e aplicativos carregadas pela VM são compartilhadas por padrão. Os carregadores de classe personalizados são compartilhados automaticamente se |estenderem o carregador de classe do aplicativo; caso contrário, eles deverão usar o Java Helper |API fornecido com a VM para acessar o cache. (Consulte Adaptando Carregadores de Classe Personalizados às Classes de Compartilhamento).
| |A acesso ao cache de classe compartilhada é limitado pelas permissões |do sistema operacional e da segurança do Java. Por padrão, |Somente um classloader registrado para |compartilhar classes poderá incluir classes no cache de classe |compartilhada. Se um Java SecurityManager estiver instalado, os |ClassLoaders (exceto os de auto-inicialização, de aplicativo e de |extensão) devem possuir permissão para compartilhar classes, incluindo |SharedClassPermissions no arquivo java.policy. (Consulte Utilizando SharedClassPermissions). A |RuntimePermission "createClassLoader" restringe a criação de novos |ClassLoaders e, portanto, também restringe o acesso ao cache.
| |Vários caches podem existir em um sistema e são especificados por nome como uma subopção |para o comando -Xshareclasses. Uma VM pode se conectar a apenas um cache |por vez. Especifique o tamanho do cache na inicialização utilizando -Xscmx<n>[k|m|g], porém esse tamanho será corrigido para o período de existência do |cache. Os caches existirão até que sejam explicitamente destruídos utilizando uma subopção |para o comando -Xshareclasses ou até que o sistema seja |reinicializado.
| |Todos os utilitários do cache são subopções para o comando -Xshareclasses. Utilize -Xshareclasses:help para ver uma lista |de subopções disponíveis.
| |O compartilhamento de classe é ativado e configurado utilizando as opções de linha de comandos -Xshareclasses e -Xscmx.
|Para ativar o compartilhamento de classe, inclua -Xshareclasses[:name=<name>] na linha de comandos do aplicativo. A VM se conectará a um cache |existente com um nome específico ou criará um novo cache com esse nome. Se |um novo cache for criado, ele será preenchido com todas as classes de |auto-inicialização e de aplicativos que estão sendo carregadas, até ficar |completamente cheio. Se dois ou mais VMs forem iniciados de forma concorrente, |todos preencherão o cache de forma concorrente.
|Para verificar se o cache foi criado, execute java |-Xshareclasses:listAllCaches . Para ver quantas classes e quantos dados das classes estão sendo compartilhados, execute java -Xshareclasses:[name=<name>],printStats. (Esses utilitários podem |ser executados após o término da VM do aplicativo ou em outra janela de comando)
|Para ver as classes que estão sendo carregadas do cache ou armazenadas nele, inclua -Xshareclasses:[name=<name>],verbose na linha de comandos do |aplicativo.
|Para excluir o cache criado, execute java -Xshareclasses:[name=<name>],delete. Você terá que excluir caches somente se eles contiverem muitas classes |stale ou se o cache estiver cheio e você desejar criar um cache maior.
|Convém ajustar o tamanho do cache para o seu aplicativo específico, uma |vez que não é provável que o padrão seja o tamanho ideal. O melhor meio de |determinar o tamanho ideal do cache é especificar um cache grande (com | -Xscmx), executar o aplicativo e utilizar |printStats para determinar quantos dados de classe foram armazenados. |Inclua um valor pequeno no valor mostrado em printStats para contingência. |Não se esqueça de que, como as classes podem ser carregadas a qualquer |momento durante a existência da VM, é melhor que essa análise seja feita |depois da conclusão do aplicativo. Contudo, um cache cheio não causa um |efeito negativo no desempenho ou capacidade de qualquer VM conectada a |ele; assim é plenamente justificável escolher um tamanho de cache menor do |que o requerido.
|Se um cache ficar cheio, uma mensagem será exibida na linha de comandos de |todas as VMs que o utilizem, e elas carregarão quaisquer classes |adicionais na própria memória de processo. As classes em um cache cheio |ainda podem ser compartilhadas, contudo ele é de somente leitura e não |pode ser atualizado com novas classes.
| |O compartilhamento de classe é particularmente útil em sistemas que |utilizam mais de uma VM com código semelhante; os sistemas se beneficiam |do consumo reduzido de memória virtual. Também é útil em sistemas que |freqüentemente inicializam e encerram VMs, que se beneficiam do |aprimoramento no tempo de inicialização.
|O código extra para criar e preencher um novo cache é mínimo. O custo do |tempo de inicialização de uma única VM é, normalmente, entre 0 e 5%, |dependendo de quantas classes são carregadas. O tempo de inicialização da |VM melhorado com um cache preenchido geralmente está entre 10% e 40%, |dependendo do sistema operacional e do número de classes carregadas. |Várias VMs executando simultaneamente exibirão benefícios de tempo de |inicialização total maiores.
|Quando você executar seu aplicativo com compartilhamento de classe, poderá utilizar as ferramentas |do sistema operacional para ver a redução no consumo de memória virtual.
| |O tamanho do cache teórico máximo é 2 GB. O cache estará |limitado pelos seguintes fatores:
| |Qualquer VM que utilize um agente JVMTI que possa modificar o bytecode não pode compartilhar |classes a não ser que a subopção modified=<modified_context> seja utilizada na |linha de comandos (veja acima). O contexto modificado é um descritor especificado pelo usuário |que descreve o tipo de modificação que está sendo executada. Todos os VMs que utilizam um determinado |contexto modificado devem modificar o bytecode de uma maneira previsível e repetida |para cada classe, de forma que as classes modificadas armazenadas no cache tenham |as modificações esperadas quando forem carregadas por outra VM. O motivo |de qualquer modificação precisar ser previsível é que as classes |carregadas do cache de classes compartilhadas não podem ser novamente |modificadas pelo agente. Observe que o bytecode |modificado e não modificado pode ser armazenado no mesmo cache. Consulte o Manual de Diagnóstico para obter mais detalhes sobre este tópico.
| |Para sistemas operacionais que podem executar os aplicativos de |32 bits e 64 bits, o compartilhamento de classe não é permitido entre VMs de 32 bits e 64 bits. |A subopção listAllCaches listará caches de 32 bits ou 64-bits, |dependendo do modo de endereço da VM que está sendo utilizado.
|O cache de classes compartilhadas requer espaço em disco para armazenar informações de identificação |sobre os caches existentes no sistema. Essas informações |estão localizadas no diretório do perfil do usuário. Se o diretório de informações de |identificação for excluído, a VM não poderá identificar as classes compartilhadas no sistema |e deverá recriar o cache.
|As permissões para acessar um |cache de classes compartilhadas são forçadas pelo sistema operacional. Por padrão, se um nome de cache não for |especificado, o nome do usuário será anexado ao nome padrão para que vários |usuários no sistema operacional criem seus próprios caches.
| |Se um SecurityManager estiver sendo utilizado em conjunto com o |compartilhamento de classe e o aplicativo em execução utilizar seus |próprios classloaders, tais classloaders devem possuir a permissão |SharedClassPermissions antes que possam compartilhar classes. Inclua |SharedClassPermissions no arquivo java.policy utilizando o nome de classe |ClassLoader (caracteres-curinga são permitidos), e "read", "write" ou |"read,write" para determinar o acesso concedido. |Exemplo:
|permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";
Se um ClassLoader sem a permissão SharedClassPermission correta tentar |compartilhar classes, a exceção AccessControlException será emitida. Não |é possível alterar ou reduzir as permissões dos classloaders de |auto-inicialização, aplicativo ou extensão.
| |A maioria dos aplicativos Java utilizará os próprios carregadores de classe da VM ou terá |carregadores de classe personalizados que estendam java/net/URLClassLoader. |Aplicativos que utilizem tais classloaders poderão compartilhar |automaticamente classes de auto-inicialização e de aplicativos. |Os carregadores de classe personalizados que não estendam java/net/URLClassLoader irão requerer |modificações para utilizar o compartilhamento de classes. Todos os |classloaders precisarão receber permissões SharedClassPermissions caso um |SecurityManager seja utilizado; consulte |Utilizando SharedClassPermissions. A IBM apresenta várias interfaces Java para diversos tipos de |classloaders personalizados, as quais permitem que os classloaders |localizem e armazenem classes no cache de classes compartilhadas. Essas classes estão no pacote |com.ibm.oti.shared. O Javadoc desse pacote é fornecido com o SDK no |arquivo docs/apidoc.zip. Consulte o Manual de |Diagnóstico para obter mais informações sobre como utilizar essas interfaces.
Se você estiver qualificado para os serviços do código do Programa relativos ao programa IBM Solutions Developer, entre em contato com esse Programa por meio de seu método normal de acesso ou pela Web em: http://www-1.ibm.com/partnerworld/.
Se você adquiriu um contrato de serviço (isto é, Linha de Suporte aos Sistemas Pessoais da IBM ou serviço equivalente por país), os termos e condições desse contrato de serviço determinam quais serviços, se existirem, você está qualificado a receber com relação ao Programa.
Os Guias do Usuário fornecidos com este SDK e o Runtime Environment foram testados utilizando os leitores de tela. É possível utilizar um leitor de tela como o Home Page Reader ou o leitor de tela JAWS com esses Guias do Usuário.
Para alterar os tamanhos de fonte nos Guias do Usuário, utilize a função fornecida com seu navegador, normalmente encontrada na opção de menu Exibir.
Para usuários que necessitam da navegação via teclado, há uma descrição do pressionamento de teclas úteis dos aplicativos Swing em "Swing Key Bindings", no site http://www-128.ibm.com/developerworks/java/jdk/additional/
|Em adição à GUI, a ferramenta iKeyman apresenta a ferramenta de linha de |comandos IKEYCMD com as mesmas funções que a |interface gráfica com o usuário (GUI) do iKeyman. O IKEYCMD permite que você gerencie teclas, |certificados e pedidos de certificados. Você pode chamar o IKEYCMD a partir de scripts shell nativos e de programas que deverão ser utilizados quando |os aplicativos precisarem incluir interfaces personalizadas nas tarefas de gerenciamento de certificados |e chaves. O IKEYCMD pode criar arquivos do banco de dados de chaves para todos |os tipos que o iKeyman suporta atualmente. O IKEYCMD pode |também criar pedidos de certificados, importar certificados assinados CA e gerenciar |certificados auto-assinados.
Para executar um comando IKEYCMD, digite:
java [-Dikeycmd.properties=<properties file>]com.ibm.gsk.ikeyman.ikeycmd <object> <action> [options]
em que:
Para obter mais informações, consulte o Guia do Usuário do iKeyman em: http://www.ibm.com/developerworks/java/jdk/security/index.html.
Se você percorrer a lista drop-down de um componente JComboBox com as teclas do cursor, o botão ou o campo editável da caixa de combinação não alterará o valor até que um item seja selecionado. Esse é o comportamento ideal para este release e melhora a acessibilidade e a utilidade assegurando que o comportamento do keyboard traversal seja consistente com o comportamento do mouse traversal.
O IBM Java Web Start v5.0 contém vários aprimoramentos de acessibilidade e usabilidade a mais que o release anterior, incluindo melhor suporte para leitores de tela e navegação do teclado aprimorada.
Você pode usar apenas a linha de comandos para ativar um aplicativo Java que seja ativado para o Web Start. Para alterar as opções de preferência, você deverá editar um arquivo de configuração, 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 definidas no Java Application Cache Viewer estão disponíveis no arquivo de configuração.
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 IBM JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS e criptografia de hardware também está disponível nesse Web site.
Observe essas limitações no IBM 32-bit SDK for Windows, v5.0:
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.
Caso tenha algum comentário sobre a utilidade, ou não, deste Guia do Usuário, gostaríamos de saber sua opinião através do correio. Observe que esse meio não foi implementado para responder perguntas técnicas - esse meio é apenas para comentários sobre a documentação. Envie seus comentários:
Letras Miúdas. Ao mandar uma mensagem para a IBM, o Cliente concorda que todas as informações contidas em sua mensagem, incluindo dados sobre feedback, como perguntas, comentários, sugestões ou informações similares, serão classificadas como não-confidenciais; a IBM não possui nenhuma obrigação de qualquer tipo em relação a tais informações e poderá reproduzir, utilizar, divulgar e distribuir as informações a terceiros sem nenhuma limitação. A IBM poderá usar todas as idéias, conceitos, conhecimentos ou técnicas contidas em tais informações para o fim que desejar, incluindo, mas não se limitando a desenvolvimento, fabricação e marketing de produtos incorporando tais informações.
Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos. A IBM pode não oferecer os produtos, serviços ou recursos discutidos neste documento em outros países. Consulte seu representante da IBM local para obter informações sobre os produtos e serviços atualmente disponíveis em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM ou quaisquer outros direitos da IBM, poderá ser utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não-IBM é de inteira responsabilidade do Cliente.
A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para:
Para pedidos de licenças com relação a informações sobre DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos, por escrito, para:
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local:
A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS DE MERCADO OU DE ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ou implícitas em certas transações; portanto, esta disposição pode não se aplicar ao Cliente.
Estas informações podem incluir imprecisões técnicas ou erros tipográficos. Periodicamente, são feitas alterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode fazer aperfeiçoamentos e/ou alterações nos produtos e/ou programas descritos nesta publicação, a qualquer momento e sem aviso prévio.
Referências nestas informações a Web sites não-IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a esses Web sites. Os materiais contidos nesses Web sites não fazem parte dos materiais deste produto IBM e a utilização desses Web sites é de responsabilidade do usuário.
A IBM pode utilizar ou distribuir qualquer informação fornecida, da forma que julgar apropriada, sem que isso incorra em qualquer obrigação para com o Cliente.
Licenciados deste programa que pretendam obter mais informações sobre o mesmo com o objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:
Tais informações podem estar disponíveis, sujeitas a termos e condições apropriados, incluindo, em alguns casos, o pagamento de uma taxa.
O programa licenciado descrito neste documento e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com Cliente IBM, Contrato de Licença de Programa Internacional IBM ou qualquer contrato equivalente.
Todos os dados de desempenho aqui descritos foram determinados em um ambiente controlado. Portanto, os resultados obtidos em outros ambientes operacionais podem variar significativamente. Algumas medidas podem ter sido tomadas em sistemas em fase de desenvolvimento e não há garantia de que tais medidas sejam as mesmas nos sistemas normalmente disponíveis. Além disso, algumas medições podem ter sido estimadas através de extrapolação. Os resultados reais podem variar. Os usuários deste documento devem verificar os dados que se aplicam ao seu ambiente específico.
As informações referentes a produtos não-IBM foram obtidas junto a fornecedores desses produtos, anúncios publicados ou outras fontes publicamente disponíveis. A IBM não testou esses produtos e não pode confirmar a precisão de desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos não-IBM. Dúvidas sobre os recursos dos produtos não-IBM devem ser encaminhadas aos fornecedores dos respectivos produtos.
IBM é uma marca registrada da International Business Machines Corporation nos Estados 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.
Outros nomes de empresas, produtos ou serviços podem ser marcas registradas ou marcas de serviço de terceiros.
Este produto também é baseado em parte do trabalho do Projeto FreeType. Para obter mais informações sobre o Freetype, consulte http://www.freetype.org.
Este produto inclui software desenvolvido pela Apache Software Foundation http://www.apache.org/.