A classe HttpURLConnection possui o método setConnectTimeout(int timeout) apenas a partir da versão 1.5 do Java. Como no projeto que estou trabalhando só posso utilzar o Runtime 1.4 por necessidade de compatibilidade com essea versão de runtime cometi um descuido e utilizei o método. Porém, como eu sabia previamente do runtime, já havia configurado no Europa o JDK compliance da seguinte maneira:
No momento que eu codifiquei o eclipse não reclamou, compilou numa boa e rodei também. Quando coloquei numa máquina com JRE 1.4 deu pau ao rodar a aplicação reclamando do método. Verifiquei as configurações novamente e estava tudo como descrito acima
Será que isso é Bug do Europa ou ta faltando configurar alguma coisa ?
“Generated .class files compatibility” afeta qual é a versão que vai no arquivo .class e isso vai determinar qual versão de JRE você precisa para rodar tal classe.
“Source compatibility” afeta quais são as funcionalidades disponíveis no código fonte, por exemplo, para usar enums ou generics você precisar ter source compatibility de pelo menos 5.0
Quem determina qual versão da classe HttpURLConnection o compilador usa para verificar/compilar é o que tem no seu build path. A classe HttpURLConnection fica no rt.jar e normalmente faz parte de um library (conjunto de jars) chamado JRE System Library. Verifique que o JRE System Library que está no seu build path é de um JRE 1.4
Rafaelprp e Sami Koivu: Não importa qual a JRE eu tenho na máquina (No meu caso estou com o JDK 6). Essas opções do eclipse são justamente para eu não precisar ter mais de uma JRE/JDK. Ele deve gerar .class e controlar o fonte de acordo com essas configurações caso contrário não serve pra nada.
Rafaelprp e Sami Koivu: Não importa qual a JRE eu tenho na máquina (No meu caso estou com o JDK 6). Essas opções do eclipse são justamente para eu não precisar ter mais de uma JRE/JDK. Ele deve gerar .class e controlar o fonte de acordo com essas configurações caso contrário não serve pra nada.[/quote]
Grande Emerson, td bem ?
Então, acho difícil corrigir esse “bug”, pois não há como o Eclipse saber se o método que vc está usando existe na versão 1.4 do java se vc não tem o java 1.4 instalado. Nesse caso pra ele saber se o método que vc está usando existe na opção que vc marcou (1.4) ele teria que manter informações de quando o método passou a existir ou foi removido (ou manter as proprias libraries anteriores).
Resumindo: Concordo com o que o Sami disse e acho dificil contornarem esse problema.
Geralmente eu mantenho vários jdk’s instalados na minha máquina, adiciono todos eles no eclipse (Installed JRE’s), e configuro qual eu vou usar no projeto.
[quote=chicobento]Grande Emerson, td bem ?
Então, acho difícil corrigir esse “bug”, pois não há como o Eclipse saber se o método que vc está usando existe na versão 1.4 do java se vc não tem o java 1.4 instalado. Nesse caso pra ele saber se o método que vc está usando existe na opção que vc marcou (1.4) ele teria que manter informações de quando o método passou a existir ou foi removido (ou manter as proprias libraries anteriores).
Resumindo: Concordo com o que o Sami disse e acho dificil contornarem esse problema.[/quote]
Seguindo essa linha de raciocínio a opção Source Compatibility e Generated .class files compatibility não serviriam pra nada portanto nem deveriam existir.
Até onde eu sei essa opção de configuração é justamente para você ter por exemplo um JDK 6 na sua máquina mas quando precisar programar mantendo compatibilidade com 1.4, 1.5 sei lá, a IDE te ajudar. Tanto que o javac tem essa opção também.
-O fato de alguém ter postado isso como um bug no bugzilla quer dizer que alguém além de você achou esse comportamento um bug. Nada mais, nada menos.
-Nota que o bug foi aberto no ano passado.
-O pessoal avaliando o “bug” disse basicamente as mesmas coisas do que eu.
Entendo que isso seria interessante, mas veja bem, para o eclipse conseguir isto, ele devia ter a informação de todas as classes em todas as versões de JRE. Ou seja, muita informação. Por motivos praticos faz mais sentido usar os próprios libs para isso do que duplicar essa informação em outro lugar. De qualquer forma, na hora de compilar, o compilador(tanto JDT quanto javac) precisa de acesso para esses libs.
É possível sim utilizar o javac para compilar no eclipse, mas o javac tem basicamente as mesmas configurações:
“-bootclasspath bootclasspath"
e
”-extdirs directories"
~= JRE System Libraries do Eclipse.
Citando o link que você passou:
Ou seja, javac também precisa dos libs para fazer o que você quer.
Eu pessoalmente acho legal ter essa flexibilidade de poder setar esses três aspectos separadamente. Porém, como alguém disse no bug, seria interessante se o Eclipse desse um warning quando você está utilizando compiler compliance diferente do lib que está no seu build path.
Não é bem assim, por exemplo, vc pode colocar o Source Compatibility como 1.4, e o Generated .class files compatibility em 1.5. E o que você ganha com isso ?
Vamos supor que você tem uma aplicação que rode em um cliente que usa java 1.4 e em outro que usa java 1.5. Você ajusta o Source Compatibility para 1.4 (dessa forma o desenvolvedor ñ poderá usar Generics, auto boxing, etc…), e pode compilar uma versão em bytecode 1.4 e outra em bytecode 1.5. Por que não gerar apenas uma versão com bytecode 1.4 ? Imagino que os bytecodes 5 e 6 tem algum tipo de tunning de performance.
Esses parâmetros estão em nível de sintaxe e bytecode e não em nível de API.
[quote=chicobento]Não é bem assim, por exemplo, vc pode colocar o Source Compatibility como 1.4, e o Generated .class files compatibility em 1.5. E o que você ganha com isso ?
Vamos supor que você tem uma aplicação que rode em um cliente que usa java 1.4 e em outro que usa java 1.5. Você ajusta o Source Compatibility para 1.4 (dessa forma o desenvolvedor ñ poderá usar Generics, auto boxing, etc…), e pode compilar uma versão em bytecode 1.4 e outra em bytecode 1.5. Por que não gerar apenas uma versão com bytecode 1.4 ? Imagino que os bytecodes 5 e 6 tem algum tipo de tunning de performance.
Esses parâmetros estão em nível de sintaxe e bytecode e não em nível de API.
[/quote]
Chico, você está correto, eu não havia pensado nisso. Achava que a compatibilidade era completa. A única coisa que me incomoda é que esse recurso é bem confuso. Parece que o recurso barraria o uso de APIs que não fossem compatíveis com o source 1.4 ou 1.x, não importa. De qualquer forma obrigado pelo esclarecimento. Mas que troço tosco heim …
Em falar nisso ainda está trampando com aquela galera ?
