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 e Runtime Environment para Linux em várias plataformas.
As plataformas às quais esse guia se aplica são:
e a todos os releases e modificações 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 e Runtime Environment para plataformas Linux, Java Technology Edition, Versão 6 e informações específicas sobre as diferenças na implementação da IBM em comparação com a implementação da Sun.
Leia esse guia do usuário juntamente com a documentação mais extensa encontrada no Web site da Sun: http://java.sun.com.
Para obter a lista de distribuições com as quais o SDK e o Runtime Environment para Linux foram testados, consulte: http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html.
(Apenas plataformas Intel de 32 bits) Esses Ambientes Virtuais são suportados:
O Manual de Diagnóstico fornece informações mais detalhadas sobre o IBM Virtual Machine para Java.
Esse guia do usuário é parte de um release e é aplicável apenas a esse release específico. Certifique-se de ter em mãos o guia do usuário apropriado ao release que você está utilizando.
Os termos "Runtime Environment" e "Java Virtual Machine" são utilizados intercambiavelmente nesse guia do usuário.
|As alterações técnicas feitas para esta |versão do guia do usuário, com exceção das alterações menores ou |óbvias, são indicadas por divisas azuis ao visualizar em um Centro de |Informações, em vermelho com barras verticais à esquerda das |alterações ao visualizar em HTML ou em uma cópia impressa em cores ou |por barras verticais à esquerda das alterações ao visualizar como um |PDF.
O Código do Programa não se destina nem foi projetado para o uso em aplicativos em tempo real, como (sem limitação) o controle on-line de aeronaves, tráfego aéreo, navegação ou comunicações de aeronaves; nem para o uso em projeto, construção, operação ou manutenção de qualquer instalação nuclear.
O IBM SDK é um ambiente de desenvolvimento para gravação e execução de applets e aplicativos compatíveis com o Java 6 Core API (Application Program Interface).
O SDK inclui o Runtime Environment para Linux, que permite somente a execução de aplicativos Java. Se você instalou o SDK, o Runtime Environment está incluído.
O Runtime Environment contém a Java Virtual Machine e os arquivos de suporte, incluindo arquivos .so não depuráveis e arquivos de classe. O Runtime Environment contém apenas um subconjunto das classes localizadas no SDK e permite suportar um programa Java no tempo de execução, mas não fornece a compilação de programas Java. O Runtime Environment para Linux não inclui qualquer das ferramentas de desenvolvimento, por exemplo, appletviewer ou o compilador Java (javac), ou classes destinadas apenas aos sistemas de desenvolvimento.
Além disso, para as plataformas IA32, PPC32/PPC64 e AMD64/EM64T, o pacote da API (Interface de Programação de Aplicativos) Java Communications é fornecido para utilização com o Runtime Environment para Linux. Informações sobre ele podem ser encontradas em Utilizando o JavaComm (Java Communications) API.
O arquivo license_xx.html contém o contrato de licença para o software Runtime Environment para Linux, em que xx é uma abreviação para o idioma. Para exibir ou imprimir o contrato de licença, abra o arquivo em um navegador da Web.
Em todo este guia do usuário, o diretório de instalação padrão do SDK se refere ao /opt/ibm/java-i386-60/. Se você não estiver utilizando o Linux IA 32-bit, o diretório de instalação padrão será diferente.
As plataformas aqui listadas possuem diferentes diretórios de instalação padrão; substitua o diretório para a plataforma que estiver utilizando quando você vir /opt/ibm/java-i386-60/:
Comandos shell Korn são utilizados em exemplos em todo este guia do usuário.
De modo geral, qualquer applet ou aplicativo que seja executado com uma versão anterior do SDK deve ser executado corretamente com o IBM SDK para Linux, v6. Não há garantia de que as classes compiladas com este release funcionem com os releases anteriores.
Para obter informações sobre problemas de compatibilidade entre releases, consulte o Web site da Sun em:
|http://java.sun.com/javase/6/webnotes/compatibility.html
http://java.sun.com/j2se/5.0/compatibility.html
http://java.sun.com/j2se/1.4/compatibility.html
http://java.sun.com/j2se/1.3/compatibility.html
Se você estiver utilizando o SDK como parte de um outro produto (por exemplo, o IBM WebSphere Application Server) e fizer upgrade de um nível anterior do SDK, talvez as classes serializadas v5.0 não sejam compatíveis. Entretanto, as classes serão compatíveis entre as atualizações de serviço.
A partir da Versão 5.0, o IBM Runtime Environment para Linux contém novas versões do IBM Virtual Machine para Java e o compilador JIT (Just-In-Time).
Se você estiver migrando de um IBM Runtime Environment mais antigo, observe que:
Os SDKs and Runtime Environments System z de 31 bits e 64 bits são executados no hardware System z9 e zSeries.
Os SDKs e o Runtime Environments são executados nos seguintes servidores ou equivalentes:
O SDK contém diversas ferramentas de desenvolvimento e um JRE (Java Runtime Environment). Esta seção descreve o conteúdo das ferramentas do SDK e o Runtime Environment.
Aplicativos totalmente escritos em Java não devem ter dependências na estrutura de diretórios do IBM SDK (ou nos arquivos desses diretórios). Qualquer dependência na estrutura de diretórios do SDK (ou nos arquivos desses diretórios) poderia resultar em problemas de portabilidade do aplicativo. Os aplicativos da JNI (
Os guias do usuário, Javadoc e a licença,os arquivos de copyright, javadoc, e diretório demo que os acompanham são a única documentação incluída neste SDK para Linux. É possível visualizar a documentação do software da Sun ou fazer download do pacote de documentos de software da Sun visitando o Web site da Sun: http://java.sun.com.
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, /opt/ibm/java-i386-60/docs/content/<locale>/LA_<locale>, contém o contrato de licença para o software SDK para Linux (em que <locale> é o nome do seu código de idioma, por exemplo, pt). Para exibir ou imprimir o contrato de licença, abra o arquivo em um navegador da Web.
Você pode instalar o IBM Java SDK e o Runtime Environment a partir de um arquivo RPM ou .tgz. A menos que deseje permitir que os usuários na máquina acessem esta instalação Java, utilize o método de instalação .tgz. Se você não tiver acesso raiz, utilize o arquivo .tgz.
Se você instalar utilizando um arquivo RPM, os arquivos Java serão instalados em /opt/ibm/java-i386-60/. Os exemplos neste guia assumem que você tenha instalado o Java nesse diretório.
Se você estiver atualizando o SDK a partir de um release anterior, faça backup de todos os arquivos de configuração e arquivos de política de segurança antes de iniciar o upgrade.
Depois do upgrade, pode ser necessário restaurar ou reconfigurar esses arquivos porque o processo de upgrade pode tê-los excluídos. Verifique a sintaxe dos novos arquivos antes de restaurar os arquivos originais porque o formato ou opções de tais arquivos podem ter sido alteradas.
O SDK depende de bibliotecas compartilhadas que, por padrão, não são instaladas para o RHEL (Red Hat Enterprise Linux).
No RHEL 4, os RPMs que contêm essas bibliotecas são:
Para incluir essas bibliotecas durante a instalação do RHEL 4:
O SDK depende de bibliotecas compartilhadas que, por padrão, não são instaladas para o RHEL (Red Hat Enterprise Linux).
No RHEL 5, os RPMs que contêm essas bibliotecas são:
Para incluir essas bibliotecas durante a instalação do RHEL 5:
Para executar o IBM SDK para Java no Red Hat Enterprise Linux Versão 5 com SELinux ativado, o Java deve ser instalado no diretório padrão ou um comando deve ser digitado.
Se o Java não estiver instalado no diretório padrão, digite:
chcon -R -t texrel_shlib_t <path_of_sdk>
Em que <path_of_sdk> é o caminho onde o Java está instalado.
Para obter mais informações sobre SELinux, consulte Introduction to SELinux na documentação do Red Hat.
Para executar o SDK, é necessário instalar as versões corretas de todas as bibliotecas necessárias ao SDK: de 32 ou de 64 bits.
No RHEL4, as versões de 64 bits dos pacotes estão disponíveis no grupo de pacotes Suporte à Compatibilidade de Arquitetura.
Você pode utilizar a ferramenta RPM para verificar quais versões dos pacotes você instalou, incluindo a opção --queryformat "%{NAME}.%{ARCH}\n" no comando RPM. Por exemplo:
/home/username : rpm --queryformat "%{NAME}.%{ARCH}\n" -q libstdc++ libstdc++.x86_64 libstdc++.i386
Um procedimento para instalar a partir de um arquivo RPM.
Para atualizar seu JVM utilizando a ferramenta rpm, é necessário desinstalar qualquer versão anterior. Para instalar duas versões da JVM em diferentes locais, utilize a opção rpm --force para ignorar o conflito de versões ou instale a JVM a partir do arquivo .tgz.
rpm -ivh ibm-java2-<arq>-sdk-6.0-0.0.<arq>.rpmou
rpm -ivh ibm-java2-<arq>-jre-6.0-0.0.<arq>.rpm
Em que <arq> representa sua arquitetura: i386, x86_64, ppc, ppc64, s390 ou s390x.
Um procedimento para instalar a partir de um arquivo .tgz.
tar -zxvf ibm-java2-sdk-60-linux-<arq>.tgzou
tar -zxvf ibm-java2-jre-60-linux-<arq>.tgz
Em que <arq> representa a sua arquitetura: i386, x86_64, ppc, ppc64, s390 ou s390x.
chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/jre chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/bin chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/lib
o pacote IBM Java também está disponível em um formato compatível do JPackage.
Para simplificar o gerenciamento do SDK, os vários componentes dele estão disponíveis agora como RPMs separados: o Java Runtime Environment, Kit de Desenvolvimento, Plug-in, JDBC, Demo, Som, Origem e Fontes base. RPM "jpackage-utils" (transferível por download de http://jpackage.org), que permite gerenciar vários RPMs Java em um sistema, também é um pré-requisito para os IBM SDKs. Para obter mais informações sobre a especificação do JPackage, consulte http://jpackage.org.
Inconsistências nas codificações de fontes no Red Hat Advanced Server
Se você alterar a variável de ambiente PATH, substituirá quaisquer ativadores Java existentes em seu caminho.
A variável de ambiente PATH permite que o Linux localize programas e utilitários, como javac, java e javadoc, a partir de qualquer diretório atual. Para exibir o valor atual do PATH, digite o seguinte em um prompt de comandos:
echo $PATH
Para incluir os ativadores Java em seu caminho:
export PATH=/opt/ibm/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
Após configurar o caminho, você poderá executar uma ferramenta digitando seu nome em um prompt de comandos a partir de qualquer diretório. Por exemplo, para compilar o arquivo Myfile.Java, em um prompt de comandos, digite:
javac Myfile.Java
O caminho de classe informa às ferramentas do SDK, como java, javac e javadoc, onde encontrar as bibliotecas de classe Java.
Você precisa configurar o caminho de classe explicitamente somente se:
Para exibir o valor atual da variável de ambiente CLASSPATH, digite o seguinte comando em um prompt shell:
echo $CLASSPATH
Se você desenvolve e executa aplicativos que utilizam diferentes ambientes de tempo de execução, incluindo outras versões que você tenha instalado separadamente, deve configurar o CLASSPATH e o PATH explicitamente para cada aplicativo. Se você executa vários aplicativos simultaneamente e utiliza diferentes ambientes de tempo de execução, cada aplicativo deve ser executado em seu próprio prompt shell.
O processo utilizado para remover o SDK e o Runtime Environment para Linux depende do tipo de instalação que você utilizou.
Veja instruções nos tópicos Desinstalando o Pacote RPM (Red Hat Package Manager) Instalável ou Desinstalando o Pacote TAR (Tape Archive) Compactado.
Um procedimento para desinstalar o pacote RPM (Red Hat Package Manager).
Para desinstalar o SDK ou o Runtime Environment para Linux, se você tiver instalado o pacote RPM instalável:
Você verá uma lista de todos os pacotes IBM Java que instalou; por exemplo:
ibm-java2-<arch>-jre-6.0-0.0.<arch> ibm-java2-<arch>-sdk-6.0-0.0.<arch>
Esta saída indica quais pacotes você pode desinstalar, utilizando o comando rpm -e; por exemplo:
rpm -e ibm-java2-<arch>-jre-6.0-0.0.<arch> rpm -e ibm-java2-<arch>-sdk-6.0-0.0.<arch>
Como alternativa, você pode utilizar uma ferramenta gráfica, como kpackage ou yast2.
Uma lista das etapas para remover o IBM SDK para Linux, v6 que foi extraído do pacote compactado.
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 20070329_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20070326_12091 (JIT ativado) J9VM - 20070326_12091_lHdSMR JIT - dev_20070326_1800 GC - 20070319_AA)As datas exatas do build e as versões serão diferentes.
|
| Você também pode listar as informações de versão
|para todos os arquivos jar disponíveis no caminho de classe, no caminho
|de classe de inicialização e no diretório de extensões, digitando o seguinte comando:
java -Xjarversion|
Você verá informações semelhantes a estas:
|... |/opt/ibm/java-i386-60/jre/lib/ext/ibmpkcs11impl.jar VERSÃO: 1.0 build_20070125 |/opt/ibm/java-i386-60/jre/lib/ext/dtfjview.jar |/opt/ibm/java-i386-60/jre/lib/ext/xmlencfw.jar VERSÃO: 1.00, 20061011 NÍVEL: -20061011 | |...|
As informações disponíveis variam para cada arquivo |jar e são extraídas das propriedades |Implementation-Version e |Build-Level contidas no manifesto do arquivo |jar.
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
export IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"
As opções à direita da linha de comandos têm precedência sobre as opções à esquerda; por exemplo, se você especificar:
java -Xint -Xjit myClass
A opção -Xjit tem precedência.
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.
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.
export JAVA_COMPILER=NONE
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.
export JAVA_COMPILER=jitcSe a variável de ambiente JAVA_COMPILER for uma cadeia vazia, o JIT permanecerá desativado. Para desativar a variável de ambiente, no prompt shell, digite:
unset 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 shell:
java -version
Se o JIT não estiver sendo utilizado, será exibida uma mensagem que inclui o seguinte:
(JIT disabled)
Se o JIT estiver sendo utilizado, será exibida uma mensagem que inclui o seguinte:
(JIT ativado)
Para obter informações adicionais sobre o JIT, consulte o Manual de Diagnóstico.
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.
Os arquivos de configuração de fonte predefinida do Linux (fontconfig.RedHat.bfc e fontconfig.SuSE.bfc) são instalados para fornecer as configurações de fonte adequadas para novas distribuições Linux empresariais.
Esses arquivos são somente para sua comodidade. A presença desses arquivos não indica que a nova distribuição Linux seja uma plataforma suportada para o IBM SDK e Runtime Environment para plataformas Linux, Java Technology Edition, Versão 6.
| | |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=/opt/ibm/java-i386-60/jre/lib/ext:/opt/ibm/java-i386-60/jre/lib/im |<classe>
|
Se você instalou o |SDK ou o |Runtime Environment em um |diretório diferente, substitua |/opt/ibm/java-i386-60/ pelo |diretório no qual você instalou o |SDK ou o |Runtime Environment.
O SDK para Linux contém muitas ferramentas e bibliotecas necessárias para o desenvolvimento de software Java.
Consulte Ferramentas SDK e Informações de Referência para obter detalhes sobre as ferramentas disponíveis.
| | |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: |
|export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
| org.apache.xerces.jaxp.SAXParserFactoryImpl
ou
|
|export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
| org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
ou
|
|export IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
| org.apache.xalan.processor.TransformerFactoryImpl
Para depurar programas Java, utilize o aplicativo JDB (Java Debugger) ou outros depuradores que se comunicam utilizando o JPDA (Java Platform Debugger Architecture), fornecido pelo SDK para Linux.
Informações adicionais sobre o diagnóstico de problemas com o uso do Java podem ser encontradas no Manual de Diagnóstico.
O JDB (Java Debugger) está incluso no SDK para Linux. O depurador é chamado pelo comando jdb; ele é conectado à JVM utilizando o JPDA.
Para depurar um aplicativo Java:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class>A JVM é iniciada, porém suspende a execução antes de iniciar o aplicativo Java.
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_socket,server=y,address=<port> <class>A JVM é iniciada, porém suspende a execução antes de iniciar o aplicativo Java.
jdb -attach <host>:<port>
A JVMDI (Java Virtual Machine Debugging Interface) não é suportada neste release. Ela foi substituída pela JVMTI (Java Virtual Machine Tool Interface).
Para obter informações adicionais sobre o JDB e o JPDA e seu uso, consulte estes Web sites:
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.
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 é SIGQUIT, o que faz com que um Javadump seja gerado.
Os tipos de sinais são Exceções, Erros, Interrupções e Controles.
A Tabela 7 a seguir mostra os sinais utilizados pela JVM. Os sinais são agrupados na tabela por tipo ou uso, como se segue:
Nome do Sinal | Tipo de Sinal | Descrição | Desativado pelo -Xrs |
---|---|---|---|
SIGBUS (7) | Exceção | Acesso incorreto à memória (alinhamento incorreto de dados) | Sim |
SIGSEGV (11) | Exceção | Acesso incorreto à memória (gravar para memória inacessível) | Sim |
SIGILL (4) | Exceção | Instrução inválida (tentativa de chamar uma instrução de máquina desconhecida) | Não |
SIGFPE (8) | Exceção | Exceção de ponto flutuante (dividir por zero) | Sim |
SIGABRT (6) | Erro | Finalização anormal. A JVM emite esse sinal sempre que detecta uma falha da JVM. | Sim |
SIGINT (2) | Interrupção | Atenção interativa (CTRL-C). A JVM sai normalmente. | Sim |
SIGTERM (15) | Interrupção | Pedido de finalização. A JVM sairá normalmente. | Sim |
SIGHUP (1) | Interrupção | Interromper. A JVM sai normalmente. | Sim |
SIGQUIT (3) | Controle | Um sinal de saída de um terminal. Por padrão, isso aciona um Javadump. | Sim |
SIGTRAP (5) | Controle | Utilizada pelo JIT. | Sim |
__SIGRTMAX - 2 | Controle | Utilizada pelo SDK. | Não |
SIGCHLD (17) | Controle | Utilizada pelo SDK para controle interno. | Não |
Utilize a opção -Xrs (reduz uso de sinais) para evitar que a JVM manipule a maior parte dos sinais. Para obter informações adicionais, consulte a página do ativador do aplicativo Java da Sun.
Os sinais 1 (SIGHUP), 2 (SIGINT), 4 (SIGILL), 7 (SIGBUS), 8 (SIGFPE), 11 (SIGSEGV) e 15 (SIGTERM) nos encadeamentos da JVM fazem com que a JVM seja encerrada. Portanto, um manipulador de sinais de aplicativo não deve tentar uma recuperação a partir desses sinais, a menos que a JVM não seja mais necessária.
O Runtime Environment contém um recurso de encadeamento de sinais. A cadeia de sinais permite que a JVM interopere mais eficazmente com o código nativo que instala suas próprias rotinas de tratamento de sinais.
O recurso de encadeamento de sinais permite que um aplicativo estabeleça um vínculo e carregue a biblioteca compartilhada libjsig.so antes das bibliotecas do sistema. A biblioteca libjsig.so assegura que as chamadas como signal(), sigset() e sigaction() sejam interceptadas para que seus manipuladores não substituam os manipuladores de sinais da JVM. Em vez disso, essas chamadas salvam as novas rotinas de tratamento de sinais ou as "encadeia" ocultas sob as rotinas de tratamento instaladas pela JVM. Mais tarde, quando qualquer um desses sinais surgir e for verificado que eles não se destinam à JVM, as rotinas de tratamento pré-instaladas serão chamadas.
Se você instalar rotinas de tratamento de sinais que utilizam sigaction(), alguns sa_flags não serão observados quando a JVM utilizar o sinal. São elas:
A biblioteca libjsig.so também oculta os manipuladores de sinais da JVM do aplicativo. Por essa razão, chamadas como signal(), sigset() e sigaction() que são feitas após o início da JVM não retornam mais uma referência ao manipulador de sinais da JVM; em vez disso, retornam qualquer manipulador que foi instalado antes da inicialização da JVM.
Para utilizar libjsig.so:
gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.cou
export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash and ksh) setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)
A variável de ambiente JAVA_HOME deve ser configurada para o local do SDK, por exemplo,/opt/ibm/java-i386-60/.
Para utilizar libjsig.a:
cc_r -q64 <outro parâmetro de compilação/link> -L/opt/ibm/java-i386-60/jre/bin -ljsig -L/opt/ibm/java-i386-60/jre/bin/j9vm -ljvm java_application.c
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.
Para compilar e vincular um aplicativo nativo com o SDK, utilize o seguinte comando:
gcc -I/opt/ibm/java-i386-60/include -L/opt/ibm/java-i386-60/jre/lib/<arq>/j9vm -ljvm -ldl -lpthread <JNI program filename>
A opção -ljvm especifica se libjvm.so é a biblioteca compartilhada que implementa a JVM. A opção -lpthread indica que você está utilizando o suporte pthread nativo; se não vincular com a biblioteca pthread, um falha na segmentação (sinal SIGSEGV) poderá ocorrer quando você executar o programa JNI.
Quatro novas classes do SDK específicas da IBM foram incluídas no pacote com.ibm.jvm para suportar a recuperação de conectores bloqueados em nível de encadeamento. As novas classes estão empacotadas no core.jar.
Essas classes permitem desbloquear os encadeamentos que tenham sido bloqueados em chamadas de rede ou sincronização. Se um aplicativo não utilizar essas classes, ele deverá finalizar o processo inteiro, em vez de interromper um encadeamento bloqueado individual.
As classes são:
Ambos, InterruptibleLockContext e InterruptibleIOContext, funcionam referenciando o encadeamento atual. Conseqüentemente, se você não utilizar InterruptibleThread, será necessário fornecer sua própria classe que estende java.lang.Thread para utilizar novas classes.
O Javadoc dessas classes é fornecido com o SDK no diretório docs/content/apidoc.
É possível ativar o suporte de página grande, em sistemas que o possuem, iniciando o Java com a opção -Xlp.
O uso da página grande é pretendido principalmente para fornecer melhorias de desempenho para aplicativos que aloquem muita memória e freqüentemente acessem essa memória. As melhorias de desempenho de página grande são ocasionadas principalmente pelo número reduzido de falhas no TLB (Translation Lookaside Buffer). Os TLB mapeia um intervalo maior de memória virtual e, portanto, causa esse aprimoramento.
O suporte de página grande deve estar disponível no kernel, e ativado, para permitir que o Java utilize páginas grandes.
Para configurar a alocação de memória de página grande, primeiro certifique-se de que o kernel que está sendo executado suporta páginas grandes. Verifique se o arquivo /proc/meminfo contém as seguintes linhas:
HugePages_Total: <número de páginas> HugePages_Free: <número de páginas> Hugepagesize: <tamanho da página, em kB>
O número de páginas disponíveis e seus tamanhos varia entre as distribuições.
Se o suporte de página grande não estiver disponível no kernel, essas linhas não existirão no arquivo /proc/meminfo. Neste caso, você deverá instalar um novo kernel que contenha o suporte para páginas grandes.
Se o suporte de página grande estiver disponível, mas não ativado, HugePages_Total será 0. Neste caso, seu administrador deverá ativar o suporte de página grande. Verifique o manual do seu sistema operacional para obter mais instruções.
Para que a JVM utilize páginas grandes, seu sistema deverá ter um número adequado de páginas grandes contíguas disponíveis. Se as páginas grandes não puderem ser alocadas, mesmo quando páginas suficientes estiverem disponíveis, possivelmente as páginas grandes não serão contíguas. A configuração do número de páginas grandes na inicialização as criará contiguamente.
As alocações de páginas grandes terão êxito somente se a JVM tiver acesso root. Para utilizar páginas grandes, execute o Java como raiz ou configure o bit suid do ativador do Java.
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 SeaMonkey, Mozilla, e Mozilla Firefox.
Navegador | Versões Suportadas |
---|---|
Mozilla | 1.7.12, 1.8 |
Firefox | 1.5, 2.0 |
Navegador | Versões Suportadas |
---|---|
Mozilla | 1.6 |
|SeaMonkey | |1.0.8 |
Release posteriores secundários de navegadores também são suportados.
Para instalar o plug-in Java, vincule-o simbolicamente para o diretório de plug-in de seu navegador.
O plug-in Java é baseado na iniciativa Open JVM Integration do Mozilla, que é utilizada com a maioria dos produtos e derivativos Mozilla, incluindo o Firefox.
Há instruções para instalar o plug-in em alguns navegadores comuns abaixo.
Vincule simbolicamente o plug-in, em vez de copiá-lo, de forma que seja possível localizar a JVM.
Apenas as versões 1.4 e posteriores do Mozilla são suportadas.
cd /usr/local/mozilla/plugins/
cd $HOME/.mozilla/plugins
ln -s /opt/ibm/java-i386-60/jre/plugin/<arq>/ns7/libjavaplugin_oji.so .Em que <arq> é a arquitetura do sistema.
Para confirmar se o Plug-in Java está disponível e ativado, selecione Ajuda -> Sobre Plug-ins no Mozilla.
É necessário vincular simbolicamente o Plug-in, em vez de copiá-lo, para que ele possa localizar a JVM.
Estas etapas tornarão o plug-in Java disponível para todos os usuários.
cd /usr/local/mozilla-firefox/plugins/
ln -s /opt/ibm/java-i386-60/jre/plugin/<arq>/ns7/libjavaplugin_oji.so .Em que <arq> é a arquitetura do sistema.
Vincule simbolicamente o plug-in, em vez de copiá-lo, de forma que seja possível localizar a JVM.
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 shell, digite:
appletviewer <nome>
em que <nome> é uma das seguintes opções:
Por exemplo, para chamar o Applet Viewer em um arquivo HTML que chama um applet, digite em um prompt shell:
appletviewer $HOME/<filename>.html
Em que filename é o nome do arquivo HTML.
Para chamar o Applet Viewer em uma página da Web, digite em um prompt shell:
appletviewer http://java.sun.com/applets/NervousText/example1.html
O Applet Viewer não reconhece a opção charset da tag <META>. Se o arquivo que o Applet Viewer carregar não for codificado como o padrão do sistema, poderá ocorrer uma exceção de E/S. Para evitar a exceção, utilize a opção -encoding ao executar o appletviewer. Por exemplo:
appletviewer -encoding JISAutoDetect sample.html
É 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.
O Java Web Start Versão 6 é instalado automaticamente quando você instala o Java utilizando os pacotes .rpm ou .tgz. Se você extrair o Java do pacote .tgz, execute o script shell jre/lib/javaws/updateSettings.sh para atualizar os arquivos .mailcap e .mime.types no sistema.
É possível chamar o Web Start de várias maneiras diferentes.
javaws <URL>Em que <URL> é o local de um arquivo .jnlp.
/opt/ibm/java-i386-60/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 Linux. O software SDK para Linux contém um Runtime Environment. No entanto, você não pode assumir que os usuários tenham o software SDK para Linux instalado.
A licença de software do SDK para Linux não permite que você redistribua qualquer dos arquivos do SDK's com o seu aplicativo. Você precisa assegurar-se de que uma versão licenciada do SDK para Linux esteja instalada na máquina de destino.
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. O cache de classe compartilhada é criado com o acesso do usuário, por padrão, a menos que a subopção da linha de comandos groupAccess seja utilizada. Somente um carregador de classes registrado para compartilhar dados de classe pode atualizar o cache de classe compartilhada.
|A memória cache é |protegida contra distorção acidental ou deliberada utilizando |proteção da página de memória. Essa não é uma garantia absoluta |contra distorção porque a JVM deve desproteger as páginas para gravar |nelas. A única maneira para garantir que um cache não possa ser |modificado é abrí-lo como de leitura.
Se um Java SecurityManager estiver instalado, carregadores de classes, excluídos os carregadores de classes padrão de auto-inicialização, de aplicativo e de extensão, devem obter permissão para compartilhar classes incluindo linhas SharedClassPermission no arquivo java.policy. (Consulte Utilizando SharedClassPermission). A RuntimePermission "createClassLoader" restringe a criação de novos carregadores de classes e, portanto, também restringe o acesso ao cache.
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 de cache que você pode especificar está limitado pela quantidade de memória física e espaço de paginação disponíveis para o sistema.
O cache para compartilhamento de classes é alocado utilizando o mecanismo de memória System V IPC Shared.
Como o espaço de endereço virtual de um processo é compartilhado entre o cache de classes compartilhadas e o heap Java, aumentar o tamanho máximo do heap Java pode reduzir o tamanho do cache de classes compartilhadas que pode ser criado.
O tamanho do cache é limitado pelas configurações do SHMMAX, o qual limita a quantidade de memória compartilhada que pode ser alocada. Você pode localizar essas configurações examinando o arquivo /proc/sys/kernel/shmmax. SHMMAX geralmente é definido como 30 MB.
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 armazenadas em /tmp/javasharedresources. Se o diretório de informações de identificação for excluído, a JVM não poderá identificar as classes compartilhadas no sistema e deverá recriar o cache. Utilize o comando ipcs para visualizar os segmentos de memória utilizados por uma JVM ou aplicativo.
Os usuários que estão executando em uma JVM devem estar no mesmo grupo para utilizar um cache de classes compartilhadas. As permissões para acessar um cache de classe compartilhado são impostas pelo sistema operacional. Por padrão, se um nome de cache não for especificado, o nome do usuário será anexado ao nome padrão para que vários usuários no sistema operacional criem seus próprios caches.
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 Linuxem plataformas IA32, PPC32/PPC64 e AMD64/EM64T. Instale o JavaComm independentemente do SDK ou Runtime Environment.
O JavaComm API fornece aos aplicativos Java uma maneira independente da plataforma de executar as comunicações das portas seriais e paralelas para tecnologias como correio de voz, fax e cartões inteligentes.
A API Java Communications suporta as portas seriais Electronic Industries Association (EIA)-232 (RS232) e as portas paralelas Institute of Electrical and Electronics Engineers (IEEE) 1284 e é suportado em sistemas com o IBM Versão 6 Runtime Environment.
Utilizando a API Java Communications, você poderá:
Certifique-se de que o SDK ou Runtime Environment esteja instalado antes de instalar a API Java Communications.
Se você utilizou o pacote RPM para instalar o Java originalmente, instale a API Java Communications a partir do arquivo RPM. Para instalar a API Java Communications a partir de um pacote RPM, consulte Instalando a API Java Communications a Partir de um Arquivo RPM.
Para instalar a API Java Communications a partir de um arquivo compactado:
tar -xvzf ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz
Em que <arch> representa sua arquitetura: i386, x86_64, ppc ou ppc64.
Certifique-se de que uma cópia do SDK ou do Runtime Environment esteja instalada antes de instalar a API Java Communications.
Se você utilizou o pacote RPM para instalar o Java originalmente, instale a API Java Communications a partir do arquivo RPM.
rpm -ivh ibm-javacomm-3.0-0.0.<arq>.rpmA API Java Communications é instalada na estrutura de diretórios do /opt/ibm/java-i386-60/.
Por padrão, os arquivos da API Java Communications são instalados no diretório /opt/ibm/java-i386-60/. Os arquivos e sua estrutura são:
Após instalar a API Java Communications, você terá que alterar o modo de acesso das portas seriais e paralelas para que os usuários possam acessar esses dispositivos.
Será preciso conceder ao usuário acesso de leitura e gravação aos dispositivos necessários. Efetue login como root e utilize os seguintes comandos, conforme se apliquem:
chmod 660 /dev/ttyS0 (também conhecido como porta serial COM1) chmod 660 /dev/lp0 (também conhecido como porta paralela LPT1) chmod 660 /dev/ttyS1 (também conhecido como porta serial COM2) chmod 660 /dev/ttyS2 (também conhecido como porta serial COM3) chmod 660 /dev/ttyS3 (também conhecido como porta serial COM4)
Inclua usuários específicos no grupo em que os dispositivos residem. Em um sistema SUSE, por exemplo, os dispositivos estão no grupo uucp. Dessa forma, os usuários podem ser incluídos no grupo uucp para obter acesso aos dispositivos.
Altere o modo de acesso de quaisquer outras portas conforme necessário.
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.
A maioria dos ThinkPads tem suas portas seriais desativadas por padrão na BIOS. Atualmente, não há como ativar as portas com o Linux (o pacote tpctl não ativa as portas se elas estiverem desativadas na BIOS).
Par ativar as portas na BIOS, é necessário utilizar a versão DOS do ThinkPad Configuration Utility que está disponível no site de download do IBM ThinkPad. Para utilizar o Utilitário de Configuração do ThinkPad, você vai precisar de um disquete DOS inicializável. Observe que o Utilitário de Configuração do ThinkPad pode ter sido instalado como parte do ThinkPad Utilities no Windows, dependendo das suas opções de instalação, e você pode executá-lo a partir de um prompt de comandos no Windows.
O aplicativo de configuração do ThinkPad fornecido com o Windows tem opções para ativar ou desativar as portas serial e paralela, mas isso não altera também as configurações na BIOS. Assim, se você utilizar este aplicativo com o Windows, as portas estarão disponíveis; entretanto, se você reinicializar o sistema com o Linux, as portas não serão ativadas.
Ao imprimir com a API Java Communications, poderá ser necessário selecionar "Avanço do Papel", "Continuar" ou uma opção semelhante na impressora.
O processo utilizado para desinstalar a API Java Communications depende de você ter instalado ou não o pacote instalável do RPM (Red Hat Package Manager) ou o pacote TAR (Tape Archive) compactado.
Desinstalando a API Java Communications utilizando o pacote RPM.
rpm -e ibm-javacomm-3.0-0.0Como alternativa, você pode utilizar uma ferramenta gráfica, como kpackage ou yast2.
Desinstalando a API Java Communications, caso você tenha instalado o pacote TAR compactado.
Exclua os seguintes arquivos do diretório em que os instalou:
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, .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.
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 Linux.
Você pode encontrar mais ajuda para diagnóstico de problemas no Manual de Diagnóstico no endereço http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.
A configuração BIOS Intercalação de memória do nó deve ser definida como DESATIVADA. Caso contrário, poderão ocorrer resultados inesperados, incluindo travamentos e interrupções do Java. Essa instrução está de acordo com a recomendação do AMD.
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/.
A criação de pares de chaves DSA de comprimentos incomuns pode demorar um tempo significativo em máquinas mais lentas. Não interprete esse atraso como uma interrupção, porque o processo será concluído se for permitido tempo suficiente. O algoritmo de geração da chave DSA foi otimizado para gerar comprimentos de chave padrão (neste caso, 512, 1024) com mais rapidez que os outros.
Programas nativos não podem criar uma VM com interfaces JNI_VERSION_1_1(0x00010001). Não é possível chamar JNI_CreateJavaVM() e transmitir-lhe uma versão de JNI_VERSION_1_1(0x00010001). As versões que podem ser aprovadas são:
A VM criada é determinada pelas bibliotecas Java presentes (ou seja, 1.2.2, 1.3.x, 1.4.x, 5.x, 6.x), e não por aquela decorrente da versão da interface JNI transmitida.
A versão da interface não afeta nenhuma área do comportamento da VM, exceto as funções disponíveis para o código nativo.
Seu gerenciador de janelas pode substituir alguns dos atalhos de teclado Java. Se você precisar utilizar um atalho de teclado Java substituído, consulte o manual do sistema operacional e altere os atalhos do teclado do gerenciador de janelas.
O Sistema Window X não pode utilizar os descritores de arquivo acima do 255. Como a JVM contém descritores de arquivos para os arquivos jar abertos, o X pode ser executado fora dos descritores de arquivos. Como uma solução alternativa, você pode definir a variável de ambiente JAVA_HIGH_ZIPFDS para que a JVM utilize descritores de arquivos mais recentes para arquivos jar.
Para utilizar a variável de ambiente JAVA_HIGH_ZIPFDS, defina-a como um valor entre 0 e 512. A JVM, então, abrirá os primeiros arquivos jar utilizando descritores de arquivo até 1024. Por exemplo, se o programa conseguir carregar 300 arquivos jar:
export JAVA_HIGH_ZIPFDS=300
Os primeiros 300 arquivos jar, então, serão carregados utilizando descritores de arquivo 724 a 1023. Os arquivos jar abertos após isso serão abertos no intervalo normal.
É possível que você não consiga utilizar a área de transferência do sistema com DBCS (Conjunto de Caracteres de Byte Duplo) para copiar informações entre aplicativos Linux e Java caso esteja executando o KDE (K Desktop Environment).
No SLES9 e distribuições mais recentes, a biblioteca de encadeamentos padrão é NPTL, que implementa os encadeamentos Java como encadeamentos nativos. Em distribuições anteriores, a biblioteca de encadeamentos padrão é LinuxThreads, que implementa os encadeamentos como novos processos. Se o número de encadeamentos Java exceder o número máximo de processos permitidos, seu programa pode ser interrompido.
O número máximo de encadeamentos disponíveis é determinado pelo menor valor de:
Entretanto, você poderá ficar sem armazenamento virtual antes de atingir o número máximo de encadeamentos.
Não há nenhuma maneira de dinstinguir entre o tempo de CPU do modo de usuário e o tempo de CPU do modo de sistema nessa plataforma. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime() e ThreadMXBean.getCurrentThreadCpuTime() todos retornam o tempo de CPU total para o encadeamento necessário.
Os resultados de KeyEvent que incluem a tecla Alt podem diferir entre gerenciadores de janelas no Linux. Além disso, diferem dos resultados de outros sistemas operacionais. Ao utilizar as configurações padrão, Ctrl+Alt+A no gerenciador de janelas KWin produz um KeyEvent, ao passo que Ctrl+Alt+A no gerenciador de janelas Metacity não produz um evento de chave.
No Sistema Linux X Window, o mapa de teclas está configurado como: 64 0xffe9 (Alt_L) 0xffe7 (Meta_L) e 113 0xffea (Alt_R) 0xffe8 (Meta_R). Para verificar isto, digite este comando em um prompt do shell:
xmodmap -pk
Esse é o motivo pelo qual o SDK considera que Meta e Alt estão sendo pressionadas juntas. Como alternativa, é possível remover o mapeamento de Meta_x, digitando o seguinte em um prompt do shell:
xmodmap -e "keysym Alt_L = Alt_L" -e "keysym Alt_R = Alt_R"
Essa alternativa poderá afetar outros aplicativos X-Window que estão sendo executados na mesma tela caso eles utilizem a tecla Meta removida.
Uma chamada para JNI_CreateJavaVM() a partir de um aplicativo JNI pode gerar uma falha de segmentação (sinal SIGSEGV); para evitá-la, reconstrua o programa JNI especificando a opção -lpthread.
Se você estiver trabalhando com vários encadeamentos simultâneos, poderá receber uma mensagem de aviso:
java.lang.OutOfMemoryError
Isso é uma indicação de que sua máquina está sendo executada sem recursos de sistema e as mensagens podem ser causadas pelas seguintes razões:
Tente ajustar o sistema para aumentar seus recursos correspondentes.
Ao executar um aplicativo Java AWT ou Swing em uma máquina Linux e exportar a exibição para uma segunda máquina, você poderá enfrentar problemas para exibir alguns diálogos se o conjunto de fontes carregadas na máquina cliente X for diferente do conjunto carregado na máquina servidor X. Para evitar esse problema, instale as mesmas fontes em ambas as máquinas.
Se o código de idioma do sistema estiver utilizando uma codificação UTF-8, algumas ferramentas do SDK poderão emitir uma sun.io.MalformedInputException. Para descobrir se o seu sistema está utilizando uma codificação UTF-8, examine as variáveis de ambiente específicas do código de idioma, como LANG ou LC_ALL, para ver se elas terminam com o sufixo ".UTF-8". Se você obtiver essa sun.io.MalformedInputException, altere os caracteres que não estejam no intervalo ASCII de 7 bits (0x00 - 0x7f) e nem representados como caracteres literais Java Unicode para caracteres literais Java Unicode (por exemplo: '\u0080'). Você também pode solucionar alternativamente esse problema removendo o sufixo ".UTF-8" das variáveis de ambiente específicas do código de idioma; por exemplo, se a sua máquina tiver o código do idioma padrão de "en_US.UTF-8", configure LANG como "en_US".
Se você estiver utilizando AMI e xcin em um ambiente de plataforma cruzada (por exemplo, se você tentar exportar a exibição entre um sistema de 32 bits e um de 64 bits ou entre um sistema big-endian e um little-endian) podem ocorrer alguns problemas. Se você tiver esse tipo de problema, faça upgrade para a versão mais recente de AMI e xcin.
Apenas para usuários dos idiomas chinês, coreano e japonês do RHEL4.
Nenhum servidor XIM está instalado por padrão. Para inserir caracteres DBCS em um aplicativo Java, instale um pacote de servidor XIM como o iiimf-x ou o kinput2.
Apenas para usuários dos idiomas chinês, coreano e japonês do RHEL4.
Se você estiver utilizando a IIIMF (Internet/Intranet Input Method Framework), utilize pacotes IIIMF incluídos no Red Hat Enterprise Linux 4 Update 2 ou posterior. Entre em contato com o Red Hat para obter orientação, no site http://www.redhat.com.
(Apenas zSeries de 64 bits) Podem ocorrer falhas de IIIMF ou uma falha ao iniciar. Para resolver o problema, faça upgrade para os pacotes mais recentes de IIIMF.
(Apenas chinês tradicional em PPC, s390 ou s390x) a IIIMF pode não funcionar. Para resolver o problema, utilize iiimf-le-xcin-0.1.7-13.EL4 ou posterior.
(Apenas chinês tradicional em PPC, s390 ou s390x) a IIIMF pode não funcionar corretamente. Para resolver o problema, utilize pacotes de IIMF incluídos no RHEL4 Update 5 ou posterior.
Apenas para usuários do idiomas chinês do RHEL4.
O código de idioma zh_CN.GB18030 não é suportado por xlib no RHEL4. xterm não pode ativar o Input Method Server para a entrada de caracteres GB18030. Utilize o código do idioma zh_CN.UTF8. Se você possuir programas ou dados de legado codificados com GB2312, GBK ou GB18030 e desejar migrá-los para o RHEL4, será necessário processá-los previamente com iconv para convertê-los para codificação UTF-8, para que os programas possam ser executados e os dados exibidos adequadamente no RHEL4 com o código de idioma zh_CN.UTF8.
Essa limitação foi solucionada no RHEL4 U3.
Podem ocorrer interrupções com xcin no RHEL4. Para resolver o problema, configure ICCHECK_DISABLE como SIM no arquivo /etc/chinese/xcin/xcinrc.
Apenas ambientes de 64 bits
No RHEL4 com xcin (servidor XIM em chinês tradicional), você pode enfrentar um comportamento inesperado, como uma falha de segmentação, com o Java em ambientes de 64 bits (como as plataformas AMD64 ou zSeries de 64 bits). Para resolver o problema, faça upgrade para o pacote mais recentes de xcin.
Apenas RHEL4.
Ao utilizar a IIIMF (Internet Intranet Input Method Framework) para entrada de caracteres DBCS, você pode encontrar problemas de alteração de foco. O problema ocorre durante a minimização de componentes de entrada ativos. Após restaurar o componente, o método de entrada alternará novamente para SBCS. O DBCS deverá, então, ser reativado manualmente.
Os seguintes componentes apresentam esse problema de alteração de foco:
RHEL4 e SLES9 Apenas
Para usuários dos idiomas japonês, chinês e coreano, não é possível utilizar XIM para inserir seus próprios caracteres nos componentes de texto de um applet Java applet em um navegador da Web. Essa limitação ocorre porque o XEmbed requer uma correção no arquivo da biblioteca X11. Como solução alternativa para essa situação, especifique o parâmetro de sistema -Dsun.awt.noxembed=true para desativar o XEmbed. Você pode utilizar o painel de controle para definir essa opção:
Essa limitação foi solucionada no RHEL4 U3 e SLES9 SP3.
Apenas plataformas Intel de 32 bits
Para usuários de texto arábico, ao utilizar Linux com uma placa de vídeo Matrox e aceleração ativada, a distorção de caracteres pode ocorrer quando da utilização de drawString para exibir fontes grandes. Esse problema é causado pelo driver dessas placas. A solução alternativa é desativar a aceleração do dispositivo.
Apenas plataformas Intel de 32 bits
No SLES 9 NPTL, o driver de porta paralela provoca um travamento de kernel e desativa um encadeamento Java. A JVM detecta esse travamento quando tenta suspender o encadeamento para Coleta de Lixo e então trava, produzindo um arquivo de núcleo e a mensagem "JVMLH030: os encadeamentos estão desaparecendo ao tentar suspender todos os encadeamentos".
O relatório 47947 do SUSE Bugzilla é emitido para esse problema. Esse erro é corrigido no SLES 9 Service Pack 1.
Apenas plataformas PPC
Se o seu código Java utiliza chamadas da JNI e alguma chamada específica tiver mais de oito parâmetros float ou double, seu código C deve ser compilado com o nível gcc-2.95.3 FSF (Free Software Foundation) do GCC (GNU C Compiler).
Apenas plataformas PPC
O pacote JavaComm não pode suportar operações de porta paralela nos kernels do SLES 9 GA e do SP1. Essa limitação é resolvida no kernel do SP2. O número do SUSE Bugzilla é 50028.
Apenas plataformas PPC de 64 bits
O compilador cruzado gcc padrão (versão 3.2-49) causa vários erros. Para gerar a biblioteca compartilhada libFileStat.so, execute:
/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I<SDK_PATH>/include FileStat.c
em que <SDK_PATH> é o caminho para o diretório SDK instalado.
Apenas plataformas zSeries
Embora o kernel do Linux nas distribuições atuais forneça suporte ao IP6 (Internet Protocol Versão 6), é possível encontrar problemas ao utilizá-lo. O suporte ao IPv6 do Java está incluso neste release, mas é aconselhável desligá-lo com a opção -Djava.net.preferIPv4Stack=true no comando java. Se você instalar um kernel que suporte totalmente o IPv6, essa opção não será necessária.
Apenas plataformas zSeries de 64 bits
O servidor do método de entrada de chinês e taiwanês (xcin) não foi testado.
O Java Desktop API pode não funcionar porque uma ou mais bibliotecas GNOME não estão disponíveis.
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, iSeries, pSeries e zSeries são marcas ou marcas registradas da International Business Machines Corporation nos Estados Unidos e/ou em outros países.
Intel é uma marca registrada da Intel Corporation nos Estados Unidos e/ou em outros países.
Java e todas as marcas registradas e logotipos baseados em Java são marcas ou marcas registradas da Sun Microsystems, Inc., nos Estados Unidos e/ou em outros países.
Linux é uma marca registrada da Linus Torvalds nos Estados Unidos e/ou em outros países.
Outros nomes de empresas, produtos ou serviços podem ser marcas comerciais ou marcas de serviço de terceiros.