Nota: Antes de utilizar estas informações e o produto que elas suportam, certifique-se de ler as informações gerais em Avisos.
Esta edição do Guia do Usuário aplica-se ao IBM Runtime Environment para Linux na Arquitetura AMD64, Java 2 Technology Edition, Versão 1.4.2.
(c) Copyright Sun Microsystems, Inc. 1997, 2003, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Todos os direitos reservados.
(c) Copyright International Business Machines Corporation, 1999, 2004. Todos os direitos reservados.
Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corporation.
Este Guia do Usuário descreve o IBM(R) Runtime Environment para Linux(TM) na Arquitetura AMD64.
O IBM Runtime Environment contém a JVM (Java(TM) Virtual Machine), as principais classes Java da Sun Microsystems e arquivos de suporte. O Runtime Environment não contém todas as classes encontradas no pacote SDK.
O Guia do Usuário oferece informações gerais sobre o Runtime Environment e informações específicas sobre as diferenças na implementação da IBM do Runtime Environment em comparação com a implementação da Sun. Leia este Guia do Usuário juntamente com a documentação mais extensa encontrada no Web site da Sun: http://java.sun.com.
O Manual de Diagnóstico IBM JVM fornece informações mais detalhadas sobre o IBM JVM.
Para obter a lista de distribuições com a qual o SDK para Linux foi
testado, visite o endereço:
http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html
Observe que 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.
Os termos "Runtime Environment" e "Java Virtual Machine" são utilizados alternadamente neste Guia do Usuário.
O Runtime Environment contém a Java Virtual Machine, classes Java e arquivos de suporte. O Runtime Environment contém apenas um subconjunto das classes localizadas no SDK e permite executar classes Java, mas não permite compilar programas Java.
O Runtime Environment para Linux inclui arquivos de objetos binários e arquivos de classe que são necessários para suportar um programa em tempo de execução. O Runtime Environment para Linux não inclui nenhuma ferramenta de desenvolvimento, como appletviewer ou o compilador Java (javac), nem classes que pertenceriam apenas a um sistema de desenvolvimento.
Além disso, o pacote de API (Aplication Programming Interface) do Java Communications é fornecido para uso com o Runtime Environment para Linux. Se você tiver instalado a API de Comunicações Java, poderá encontrar informações sobre ela na publicação JavaComm API User Guide.
O arquivo LICENSE_xx.html contém o contrato de licença para o software Runtime Environment para Linux. (xx é a abreviação do idioma.)
Para exibir ou imprimir o contrato de licença, abra o arquivo em um navegador da Web.
O compilador JIT (Just-In-Time) (libjitc.so) gera dinamicamente o código de máquina para as seqüências de bytecode freqüentemente utilizadas nos aplicativos e applets do Java enquanto são executados.
O Runtime Environment para Linux inclui o JIT (libjitc.so), que é ativado por padrão. É possível desativar o JIT para ajudar no isolamento de um problema com um aplicativo Java, um applet ou o próprio compilador.
Para desativar o JIT, utilize a opção -Xint. No janela de prompt shell em que o aplicativo é executado, digite:
java -Xint classe
Para verificar se o JIT está ativado ou não, em um prompt do shell, digite:
java -version
Se o JIT estiver sendo utilizado, será exibida uma mensagem que inclui:
(JIT enabled)
Se o JIT não estiver sendo utilizado, será exibida uma mensagem que inclui:
(JIT disabled)
A JNI (Java Native Interface) está incluída no Runtime Environment. Para obter informações sobre como utilizar o JNI, consulte o Web site da Sun: http://java.sun.com/j2se/1.4.2/docs/guide/jni.
A IBM não suporta a Native Method Interface neste release. Não use esta interface em seus aplicativos.
Depois de instalar o Runtime Environment, edite o script de login de shell e inclua esse diretório na instrução PATH:
/opt/IBMJava2-142/jre/bin
Se você tiver instalado o Runtime Environment em um diretório diferente de /opt/IBMJava2-142/, substitua /opt/IBMJava2-142/ pelo diretório no qual o Runtime Environment foi instalado.
O processo que você utiliza para remover o Runtime Environment para Linux depende se você instalou o pacote RPM (Red Hat Package Manager) instalável ou o pacote TAR (Tape Archive) compactado. Veja instruções nos tópicos Desinstalando o Pacote RPM (Red Hat Package Manager) Instalável ou Desinstalando o Pacote TAR (Tape Archive) Compactado.
Para desinstalar o Runtime Environment para Linux se tiver instalado o pacote RPM instalável:
rpm -e IBMJava2-JRE-1.4.2-0.0 Para desinstalar o Runtime Environment para Linux, caso tenha instalado o pacote TAR compactado:
A ferramenta java ativa um aplicativo Java. Ela requer um nome de classe Java inicial como parâmetro. Se esse nome não for fornecido, uma mensagem de uso será impressa.
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 após o nome da classe ou nome do arquivo JAR são transmitidos para a função principal.
O comando javaw é idêntico ao java, exceto que o javaw não possui janela de console associada.Utilize javaw quando não desejar que uma janela de prompt de comandos seja exibida. O ativador javaw exibirá uma caixa de diálogo com informações sobre erros se houver falha na ativação.
Os comandos java e javaw utilizam a seguinte sintaxe:
java [ opções ] class [ argumentos ... ] java [ opções ] -jar file.jar [ argumentos ... ] javaw [ opções ] class [ argumentos ... ] javaw [ opções ] -jar file.jar [ argumentos ... ]
Os itens entre colchetes são opcionais.
Se a opção -jar for especificada, o arquivo JAR nomeado irá conter arquivos de classe e recurso para os aplicativos com a classe de inicialização indicada pelo cabeçalho do manifesto Main-Class.
O ativador possui um conjunto de opções padrão suportadas no ambiente de tempo de execução atual e que serão suportadas em releases futuros. Além disso, há um conjunto de opções fora do padrão.
As opções -X listadas a seguir não são opções padrão e, portanto, estão sujeitas a alterações sem aviso prévio.
O comando java e outros comandos do ativador java (como javaw) permitem que um nome de classe seja especificado como qualquer caractere Unicode que esteja no conjunto de caracteres da localidade atual.
Também é possível especificar qualquer caractere Unicode nos argumentos e no nome de classe utilizando seqüências de escape java. Para fazê-lo, será necessário especificar -Xargencoding. Para especificar um caractere Unicode, utilize seqüências de escape no formato \u####, em que # é um dígito hexadecimal (0 a 9, A a F).
Como alternativa, para especificar que o nome de classe e os argumentos de comando possuem a codificação UTF8, utilize -Xargencoding:utf8 ou, na codificação ISO8859_1, utilize -Xargencoding:latin.
Os comandos java e javaw fornecem mensagens de saída traduzidas. Essas mensagens são diferentes com base no código do idioma em que o Java está sendo executado. As descrições detalhadas de erros e outras informações de depuração retornadas por java estão em inglês.
É possível especificar um nome de classe como um nome de arquivo completo, incluindo um caminho completo e a extensão .class. Em versões anteriores, apenas era possível especificar a classe relativa a CLASSPATH e a extensão .class não era permitida. O uso do nome de arquivo completo permite que você ative um aplicativo java pelo desktop ou pelo ativador de arquivos. Se você especificar um arquivo .class com caminho e extensão, o caminho especificado será colocado em CLASSPATH. Por exemplo, o comando java ~/myapp/thisapp.class é equivalente a especificar java -classpath ~/myapp thisapp.
A opção -Xgcpolicy de tempo de execução JVM especifica a política de coleta de lixo.
-Xgcpolicy utiliza os valores optthruput (o padrão), optavgpause ou gencon. A opção controla o comportamento do coletor de lixo, fazendo trocas entre o throughput do aplicativo e o sistema geral, e faz com que os tempos de pausa sejam causados pela coleta de lixo.
O formato da opção e seus valores são:
-Xgcpolicy:optthruput
-Xgcpolicy:optavgpause
-Xgcpolicy:gencon
Quando a tentativa de um aplicativo em criar um objeto não pode ser atendida imediatamente no espaço disponível no heap, o coletor de lixo é responsável pela identificação de objetos não referidos (lixo), por excluí-los e retornar o heap para um estado no qual pedidos de alocação imediatos e subseqüentes possam ser atendidos rapidamente. Tais ciclos de coleta de lixo introduzem pausas inesperadas ocasionais na execução do código do aplicativo. Como os aplicativos aumentam de tamanho e complexidade e os heaps tornam-se correspondentemente maiores, esse tempo de pausa da coleta de lixo tende a aumentar de tamanho e importância. O valor padrão de coleta de lixo, 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 quantidade de lixo.
A JVM utiliza duas técnicas para reduzir tempos de pausa:
A opção de linha de comandos -Xgcpolicy:optavgpause solicita o uso da coleta de lixo simultânea para reduzir significativamente o tempo gasto em pausas para coletas de lixo. A Coleta de Lixo Simultânea reduz o tempo de pausa executando algumas atividades de coleta de lixo simultaneamente à execução normal de programas para minimizar a interrupção causada pela coleta do heap. A opção -Xgcpolicy:optavgpause também limita o efeito do aumento do tamanho de heap durante a pausa para coleta de lixo. A opção -Xgcpolicy:optavgpause é mais útil para configurações que apresentam grandes heaps. Com o tempo de pausa reduzido, você poderá perceber uma certa redução no rendimento do processamento dos aplicativos.
Durante a coleta de lixo simultânea, um tempo significativo é gasto com a identificação de objetos relativamente resistentes que não conseguem ser coletados. Se a Coleta de Lixo concentrar-se apenas nos objetos com a maior tendência de serem recicláveis, será possível reduzir ainda mais os tempos de pausa de alguns aplicativos. A Coleta de Lixo com Base em Gerações obtém o mesmo resultado dividindo o heap em duas "gerações", as áreas de "desenvolvimento" e "estabilidade". Os objetos são colocados em uma dessas áreas dependendo da duração. A área de desenvolvimento é a menor e contém objetos mais recentes, enquanto a área de estabilidade é maior e contém objetos mais antigos. Os objetos são alocados primeiro à área de desenvolvimento; se persistirem por um período suficiente, avançarão em algum momento para a área de estabilidade.
A Coleta de Lixo com Base em Gerações depende da curta duração da maioria dos objetos. Ela reduz os tempos de pausa concentrando-se na tentativa de reivindicar o armazenamento na área de desenvolvimento, pois essa área inclui a maioria do espaço reciclável. Em vez de tempos de pausa ocasionais, mas demorados, para coletar todo o heap, a área de desenvolvimento é coletada com mais freqüência e, se essa área for pequena o bastante, os tempos de pausa serão relativamente menores. Entretanto, a Coleta de Lixo com Base em Gerações apresenta a desvantagem da possibilidade de que, com o passar do tempo, a área de estabilidade fique lotada se vários objetos persistirem por muito tempo. Para minimizar o tempo de pausa quando essa situação ocorrer, utilize uma combinação da Coleta de Lixo Simultânea com a Coleta de Lixo com Base em Gerações. A opção -Xgcpolicy:gencon solicita o uso combinado dessas duas técnicas para ajudar a minimizar o tempo gasto com qualquer pausa para coleta de lixo.
Se o heap Java estiver quase cheio, e houver pouco lixo para ser recuperado, os pedidos de novos objetos poderão não ser atendidos rapidamente por não haver espaço disponível de imediato. Se o heap for operado com capacidade quase cheia, o desempenho do aplicativo poderá ser afetado, independentemente de quais opções anteriores forem utilizadas; e, se os pedidos de mais espaço para o heap continuarem a ser feitos, o aplicativo receberá uma exceção OutofMemory, o que resultará na finalização da JVM caso a exceção não seja capturada e tratada. Nesse ponto, a JVM gerará um arquivo de diagnóstico "javadump". Nessas condições, recomenda-se aumentar o tamanho do heap utilizando a opção -Xmx ou reduzir o número de objetos do aplicativo em uso.
Quando surge um sinal que é do interesse da JVM, uma rotina de tratamento de sinais é chamada. Essa rotina de tratamento de sinais determina se o sinal foi chamado por causa de um encadeamento Java ou não-Java.
Se o sinal for por causa de um encadeamento Java, a JVM assumirá o controle do tratamento do sinal. Se uma rotina de tratamento de aplicativo para esse sinal for instalada e você não tiver especificado a opção de linha de comandos -Xnosigchain, após o término do processamento da JVM, essa rotina de tratamento será chamada.
Se o sinal for por causa de um encadeamento não-Java e o aplicativo que instalou o JVM tiver instalado anteriormente sua própria rotina de tratamento para o sinal, o controle será fornecido a essa rotina de tratamento. Caso contrário, se o sinal for solicitado pela JVM ou pelo aplicativo Java, ele será ignorado ou a ação padrão será executada.
Com relação aos sinais de exceção e erro, a JVM:
Com relação aos sinais de interrupção, a JVM insere também uma seqüência de encerramento controlado, mas dessa vez ela é tratada como uma terminação normal:
O encerramento é idêntico ao encerramento iniciado por uma chamada para o método System.exit().
Outros sinais utilizados pela JVM destinam-se a propósitos de controle interno e não causam a sua terminação. O único sinal de controle de interesse é SIGQUIT, o que faz com que um Javadump seja gerado.
A Tabela 1 a seguir mostra os sinais utilizados pela JVM. Os sinais são agrupados na tabela por tipo ou uso, como se segue:
| Nome do Sinal | Tipo de Sinal | Descrição | Desativado pelo -Xrs |
|---|---|---|---|
| SIGBUS | Exceção | Acesso incorreto à memória (alinhamento incorreto de dados) | Não |
| SIGSEGV | Exceção | Acesso incorreto à memória (gravar para memória inacessível) | Não |
| SIGILL | Exceção | Instrução inválida (tentativa de chamar uma instrução de máquina desconhecida) | Não |
| SIGFPE | Exceção | Exceção de ponto flutuante (dividir por zero) | Não |
| SIGABRT | Erro | Finalização anormal. A JVM emite esse sinal sempre que detecta uma falha da JVM. | Não |
| SIGINT | Interrupção | Atenção interativa (CTRL-C). A JVM sai normalmente. | Sim |
| SIGTERM | Interrupção | Pedido de finalização. A JVM sairá normalmente. | Sim |
| SIGHUP | Interrupção | Interromper. A JVM sai normalmente. | Sim |
| SIGQUIT | Controle | Um sinal de saída de um terminal. JVM uses this for taking Javadumps. | Não |
| SIGPIPE | Controle | Canal interrompido. Defina como SIG_IGN | 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 de aplicativos Java da Sun em http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.
Os sinais 1 (SIGHUP), 2 (SIGINT), 4 (SIGILL), 7 (SIGBUS), 8 (SIGFPE), 11 (SIGSEGV) e 15 (SIGTERM) em encadeamentos da JVM fazem com que a JVM seja encerrada. Portanto, uma rotina de tratamento de sinais de aplicativo não deve tentar uma recuperação a partir desses sinais, a menos que os serviços da JVM não sejam mais necessários.
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 suas rotinas de tratamento não substituam as rotinas de tratamento de sinais da JVM. Em vez disso, essas chamadas salvam as novas rotinas de tratamento de sinais, ou as "encadeia" ocultas sob as rotinas de tratamento instaladas pela JVM. Mais tarde, quando qualquer um desses sinais surgir e for verificado que eles não se destinam à JVM, as rotinas de tratamento pré-instaladas serão chamadas.
Para utilizar 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)(Assumindo que JAVA_HOME esteja configurado; caso contrário, utilize /opt/IBMJava2-142/jre.)
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 do aplicativo rotinas de tratamento de sinais da JVM. 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 à rotina de tratamento de sinais da JVM; em vez disso, retornam qualquer rotina de tratamento que foi instalada antes da inicialização da JVM.
O conjunto de encadeamento para as Rotinas de Tratamento de Conexão do RMI não é ativado por padrão.
Para ativar o conjunto de conexão implementado no nível TCPTransport do RMI, defina a opção
-Dsun.rmi.transport.tcp.connectionPool=true (ou qualquer valor que não seja nulo)
Essa versão do Runtime Environment não possui nenhuma definição que você possa utilizar para limitar o número de encadeamentos no conjunto de conexão.
Para obter informações adicionais, consulte o site do Java da Sun: http://java.sun.com.
Para obter o número de compilação e versão IBM, em um prompt do shell , digite:
java -version
Em um sistema Linux de pilha não-flutuante, independentemente do valor que for definido para -Xss, será fornecido um tamanho mínimo de pilha nativa de 256 KB para cada encadeamento. Em um sistema Linux de pilha flutuante, os valores -Xss são aceitos. Por isso, se você estiver migrando de um sistema Linux de pilha não-flutuante, será necessário assegurar-se de que todos os valores de -Xss sejam grandes o suficiente e que não dependam de um mínimo de 256 KB.
Em sistemas DBCS (Conjunto de Caracteres de Byte Duplo), se deseja trocar o método de entrada, você deve utilizar a classe java.util.prefs.Preferences em vez de utilizar as variáveis de ambiente IBMJAVA_INPUTMETHOD_SWITCHKEY e IBMJAVA_INPUTMETHOD_SWITCHKEY_MODIFIERS. Consulte Especificação de Estrutura do Método de Entrada da Sun em detalhes.
Após desenvolver seu produto e estar pronto para expedi-lo, você precisa instalar o produto em um sistema de usuário, configurar o sistema do usuário para suportar o software e configurar o ambiente de tempo de execução.
Se você utilizar o Runtime Environment para Linux, deverá assegurar-se de que o procedimento de instalação não sobreponha uma instalação já existente (a menos que o Runtime Environment para Linux seja uma versão anterior).
Para redistribuir o Runtime Environment para Linux, você pode instalá-lo em seu próprio sistema e em seguida copiar os arquivos requeridos do Runtime Environment para o seu conjunto de instalação. Se você escolher essa abordagem, deverá incluir todos os arquivos fornecidos com o Runtime Environment para Linux. O software do Runtime Environment para Linux poderá ser redistribuído somente se todos os arquivos forem incluídos. De fato, quando você envia o aplicativo, ele tem sua própria cópia do Runtime Environment para Linux.
Para obter informações específicas sobre os arquivos que devem ser redistribuídos, consulte o contrato de licença que acompanha esse produto.
As seções a seguir explicam as limitações conhecidas do Runtime Environment para Linux.
O número máximo de encadeamentos disponíveis é determinado pelos valores mínimos de:
Entretanto, você poderá ficar sem armazenamento virtual antes de atingir o número máximo de encadeamentos.
xmodmap -pkEsse é o motivo pelo qual o SDK considera que Meta + Alt estão sendo processados juntos. 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"
Caso tenha algum comentário sobre a utilidade, ou não, deste Guia do Usuário, gostaríamos de saber sua opinião através do correio. Observe que esse meio não foi implementado para responder perguntas técnicas - ele serve apenas para comentários sobre a documentação. Envie seus comentários:
Letras Miúdas. Ao mandar uma mensagem para a IBM, o Cliente concorda que todas as informações contidas em sua mensagem, incluindo dados sobre feedback, como perguntas, comentários, sugestões ou informações similares, serão classificadas como não-confidenciais; a IBM não possui nenhuma obrigação de qualquer tipo em relação a tais informações e poderá reproduzir, utilizar, divulgar e distribuir as informações a terceiros sem nenhuma limitação. A IBM poderá usar todas as idéias, conceitos, conhecimentos ou técnicas contidas em tais informações para o fim que desejar, incluindo, mas não se limitando a desenvolvimento, fabricação e marketing de produtos incorporando tais informações.
Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos. A IBM pode não oferecer os produtos, serviços ou recursos discutidos neste documento em outros países. Consulte seu representante da IBM local para obter informações sobre os produtos e serviços atualmente disponíveis em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM ou quaisquer outros direitos da IBM, poderá ser utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não-IBM é de inteira responsabilidade do Cliente.
A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para:
Para pedidos de licenças com relação a informações sobre DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos, por escrito, para:
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local:
A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS DE MERCADO OU DE ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ou implícitas em certas transações; portanto, esta disposição pode não se aplicar ao Cliente.
Estas informações podem incluir imprecisões técnicas ou erros tipográficos. Periodicamente, são feitas alterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode fazer aperfeiçoamentos e/ou alterações nos produtos e/ou programas descritos nesta publicação, a qualquer momento e sem aviso prévio.
Referências nestas informações a Web sites não-IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a esses Web sites. Os materiais contidos nesses Web sites não fazem parte dos materiais deste produto IBM e a utilização desses Web sites é de responsabilidade do usuário.
A IBM pode utilizar ou distribuir qualquer informação fornecida, da forma que julgar apropriada, sem que isso incorra em qualquer obrigação para com o Cliente.
Licenciados deste programa que pretendam obter mais informações sobre o mesmo com o objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:
Tais informações podem estar disponíveis, sujeitas a termos e condições apropriados, incluindo, em alguns casos, o pagamento de uma taxa.
O programa licenciado descrito neste documento e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com Cliente IBM, Contrato de Licença de Programa Internacional IBM ou qualquer contrato equivalente.
Todos os dados de desempenho aqui descritos foram determinados em um ambiente controlado. Portanto, os resultados obtidos em outros ambientes operacionais podem variar significativamente. Algumas medidas podem ter sido tomadas em sistemas em fase de desenvolvimento e não há garantia de que tais medidas sejam as mesmas nos sistemas normalmente disponíveis. Além disso, algumas medições podem ter sido estimadas através de extrapolação. Os resultados reais podem variar. Os usuários deste documento devem verificar os dados que se aplicam ao seu ambiente específico.
As informações referentes a produtos não-IBM foram obtidas junto a fornecedores desses produtos, anúncios publicados ou outras fontes publicamente disponíveis. A IBM não testou esses produtos e não pode confirmar a precisão de desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos não-IBM. Dúvidas sobre os recursos dos produtos não-IBM devem ser encaminhadas aos fornecedores dos respectivos produtos.
IBM é uma marca registrada da International Business Machines Corporation nos Estados e/ou em outros países.
Java e todas as marcas registradas e logotipos baseados em Java são marcas registradas 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 registradas ou marcas de serviço de terceiros.
Este produto inclui software desenvolvido pela Apache Software Foundation http://www.apache.org/.