Antes de utilizar estas informações e o produto suportado por elas, leia as informações em Avisos.
Essa edição do guia do usuário aplica-se ao IBM SDK de 32 bits e Runtime Environment para Windows, Java Technology Edition, Versão 6, 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, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Todos os direitos reservados.
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.
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.
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.
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:
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.
Uma lista de classes e ferramentas que podem ser utilizadas com o Runtime Environment padrão.
Uma lista de ferramentas e informações de referência incluída com o SDK padrão.
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.
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.
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.
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.
Utilize a instalação assistida para instalar o SDK ou JRE em um cliente único.
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.
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.
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
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.
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
É 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.
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.
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:
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
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.
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:
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.
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.
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.
Uma rápida visão geral dos comandos java e javaw.
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.
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 ... ]
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.
java -versionVocê 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.
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:
java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
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.
As definições das opções padrão.
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.
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.
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''%*'
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 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.
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.
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 <class>
java -Xint < classe>
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.
set JAVA_COMPILER=jitcÉ 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. Se a variável de ambiente JAVA_COMPILER for uma cadeia vazia, o JIT permanecerá desativado. Para desativar a variável de ambiente, no prompt de comandos, digite:
set JAVA_COMPILER=
java -Djava.compiler=jitc <class>
java -Xjit <class>
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.
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.
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:
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.
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.
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.
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.
| | |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:
|java |-Djava.ext.dirs=C:\Arquivos de |Programas\IBM\Java60\jre\lib\ext;C:\Arquivos de |Programas\IBM\Java60\jre\lib\im |<classe>
|
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.
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.
| | |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.
|O |IBM |SDK para |Java |contém as seguintes bibliotecas XML.
|XML4J é um analisador de validação que fornece suporte para os |seguintes padrões: |
|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 é 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.
|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: |
|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: |
|Os seguintes |provedores de serviços controlam as bibliotecas de processamento de |XML utilizadas pelo |Java: |
|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:
|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 | |
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.
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.
Os seguintes |recursos opcionais de StAX não são suportados pelo XL XP-J: |
|As seguintes propriedades são suportadas pela implementação do |javax.xml.stream.XMLInputFactory, conforme |descrito no |XMLInputFactory |Javadoc.
| |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.
|As seguintes propriedades são suportadas pela implementação do |javax.xml.stream.XMLStreamReader, conforme |descrito no |XMLStreamReader |Javadoc.
| |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.
|As seguintes propriedades são suportadas pela implementação do |javax.xml.stream.XMLOutputFactory, conforme |descrito no |XMLOutputFactory |Javadoc.
| |Nome da Propriedade | |Suportado | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Sim | |
As seguintes propriedades são suportadas pela implementação do |javax.xml.stream.XMLStreamWriter implementation, |conforme descrito no |XMLStreamWriter |Javadoc.
| |Nome da Propriedade | |Suportado | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Sim | |
As |propriedades em objetos XMLStreamWriter são de leitura.
| | |XL TXE-J é uma biblioteca XSLT que contém o interpretador |XSLT4J 2.7.8 e um compilador XSLT.
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 | |
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.
| |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: |
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
| org.apache.xerces.jaxp.SAXParserFactoryImpl
ou
|
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
| org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
ou
|
|set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
| org.apache.xalan.processor.TransformerFactoryImpl
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.
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:
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.
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:
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.
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.
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:
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");
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:
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.
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:
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.
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.
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).
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.
É 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".
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.
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.
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.
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.
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.
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>
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.
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.
Para desativar a fragmentação, configure o tamanho do fragmento para 0 bytes:
java -Dcom.ibm.CORBA.FragmentSize=0 <myapp>
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.
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 |
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.
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:
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.
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.*;.
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.
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/.
O plug-in Java suporta Internet Explorer, Netscape, Mozilla, e Mozilla Firefox.
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.
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:
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.
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:
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.
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.
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
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
É 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.
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:
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.
javaws <URL>Em que <URL> é o local de um arquivo .jnlp.
C:\Arquivos de
Programas\IBM\Java60\jre\bin\javaws|-viewer
Todos os aplicativos do Java Web Start são armazenados no Java Application Cache. Um aplicativo somente é transferido por download se a versão mais recente não estiver no cache.
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.
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.
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:
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.
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.
|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.
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.
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.
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.
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.
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.
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:
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.
ConsulteManual de Diagnóstico para obter informações adicionais.
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.
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.
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.
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:
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.
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.
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.
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.
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á:
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:
Após instalar o Java Communications API, você deve:
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.
Ao imprimir com a API Java Communications, poderá ser necessário selecionar "Avanço do Papel", "Continuar" ou uma opção semelhante na impressora.
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\.
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/.
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.
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/.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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/.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.