Método - limite de 65535 excedido

Ola

Esse é um limitante do byecode do java: uma classe nao pode ter mais de 2^16 bytes. Nao daria pra aumentar, ja que o java usa 16 bits para se enderecar a uma posicao do codigo:
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#88659

Sem duvida isso é um grande indicador que o sistema esta com um problema grave em relacao a MVC e deve ter muito scriptlet dentro dos seus JSP.

Em vez de quebrar em includes, refatore o codigo e quebre em tag files, custom tags e beans java!!!

jsp:include PAGE em vez de jsp:include FILE deve ajudar tambem, mas voce vai continuar com o problema do codigo estar muito misturado.

ao que parece esses caras tiveram o mesmo problema que você:

Paulo Silveira:

Ola

Esse é um limitante do byecode do java: uma classe nao pode ter mais de 2^16 bytes. Nao daria pra aumentar, ja que o java usa 16 bits para se enderecar a uma posicao do codigo:
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#88659

Sem duvida isso é um grande indicador que o sistema esta com um problema grave em relacao a MVC e deve ter muito scriptlet dentro dos seus JSP.

Em vez de quebrar em includes, refatore o codigo e quebre em tag files, custom tags e beans java!!!

jsp:include PAGE em vez de jsp:include FILE deve ajudar tambem, mas voce vai continuar com o problema do codigo estar muito misturado.

Obrigado mas como havia comentado não quero mexer no código fonte, não quero e não posso refatorar o código… pois o mesmo é gerado por uma ferramenta… a ferramenta pega código escrito na linguagem X, utilizada pelo cliente, e transforma em JSP - java.

O código gerado verdadeiramente é uma salada… mas a origem, a linguagem X é estruturada… não quero mexer no código gerado pois neste caso terei que mexer na ferramenta, e mexer na ferramenta é algo bastante complexo.

Espero que tenham entendido o meu problema… infelizmente creio que terei que mexer na ferramenta que gera o código java e é justamente isso que quero evitar. Seria muito mais simples: troque o parametro XPTO do global.jsp de 65535 para o valor desejado.

bobmoe:

ao que parece esses caras tiveram o mesmo problema que você:
http://www.velocityreviews.com/forums/t146001-reached-the-65535-bytes-limit.html

Pois é

E a solução apontada neste post e em todos os outros que vi na net sugerem: otimizar código fonte. E isto é justamente o que a gente não deseja… pois quem gera o fonte é uma ferramenta.

Obrigado pela ajuda
latmantovani

qual é a ferramenta?

nao deve ser tao complicado de trocar os includes de FILE para PAGE, e mtas vezes essa modificacao nao tem impacto funcional.

mas esse numero de 65535 nao da pra mudar mesmo, é da JVM.

Paulo Silveira:

qual é a ferramenta?

nao deve ser tao complicado de trocar os includes de FILE para PAGE, e mtas vezes essa modificacao nao tem impacto funcional.

mas esse numero de 65535 nao da pra mudar mesmo, é da JVM.

O cliente esta migrando de ASP para JSP. As páginas ASP funcionam normalmente porém as JSP dão o erro informado.

Obrigado pela ajuda.

Ou seja, você (ou seu chefe, ou seu patrão, ou então a companhia que está contratando seus serviços) provavelmente pagou por ela. Chame o suporte técnico e exija uma solução, ou seu dinheiro de volta.

thingol:

Ou seja, você (ou seu chefe, ou seu patrão, ou então a companhia que está contratando seus serviços) provavelmente pagou por ela. Chame o suporte técnico e exija uma solução, ou seu dinheiro de volta.

Quisera eu fosse tão simples assim :)… mas esta é outra discussão.

Tecnicamente, ao que parece, não existe outra solução a não ser alteração na ferramenta em questão, correto?

ou alterar o fonte gerado… ai!

isso não vai acontecer pois o cliente teria que alterar o fonte gerado e certamente o cliente não vai querer fazer isso, e com toda razão a ele. Se não precisavam fazer isso anteriormente, porque precisarão fazer agora?

A gente mudar o fonte… inviável… são mais de 3000 telas (fora as novas que estão sendo criadas), sendo que são 2 gerações por dia… imagina, teria que contratar ao menos uma pessoa pelo resto da vida só pra fazer isso. Economicamente inviável.

Valeu pela ajuda. Vamos ver quais são os work arounds possíveis, se é que existem alternativas.

Você pode tentar compilar as classes Java criadas pelo seu JSP com o Jikes (compilador do Eclipse) em vez do javac - acho que isso é possível a partir do Tomcat 6, se não me engano. Acho que o Jikes tem um limite um pouco maior, mas não tenho certeza.

Como normalmente esse problema é porque as classes ficam grandes devido à grande quantidade de strings (não exatamente código), esse problema pode ser contornado, dependendo do seu web container, com alguma configuração. No caso do Tomcat, se você tiver um pouco de sorte, você pode usar “trimSpaces” (configuração em web.xml) para fazer 2 coisas:

• Tirar os espaços em branco que aparecem aos montes nas páginas HTML, entre os tags;
• Dependendo da página, talvez ela seja ligeiramente reduzida e acabe cabendo nesse tal limite.

http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html

hum, talvez um obfuscador ajude bastante, e tirar as opcoes de compilar com info de debug. vai certamente diminuir bastante o tamanho do bytecode. mas vc so vai postergar o seu problema!

poxa, desculpa o comentário inútil, mas só eu que fiquei com medo da ferramenta?!

posta o nome ae pra gente passar longe hehehe

Talvez eu esteja com muito sono, já, mas vejo um problem em usar um obfuscador. Os obfuscadores normalmente trabalham com código compilado.

1. Não sei se o .class é gerado nesse caso.

2. E se for gerado com métodos com mais de 65535 bytes, o código vai estar corrupto. Os blocos try/catch/finally que ficam além do limite vão estar apontando para lugares errados. Tudo bem que o código gerado talvez não tenha tratamento algum deste tipo.

[]s,
Sami

É gerado sim.

Mas imagine a mutreta pra obfuscar JSPs compilados pelo tomcat? afff… esquece minha ideia

Uia…
Essa ferramenta deve ser uma gambiarra só
iauehieauhieauhaieuheaiuheaiuheauiheai

Também gostaria de saber o nome da ferramenta…