Método - limite de 65535 excedido

A empresa em que trabalho possui uma ferramenta que gera páginas JSP a partir de outras fontes de dados.

Algumas páginas apresentam o erro abaixo (as maiores páginas geradas):

The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit

Gostaria de saber se existe algum parametro que poderia configurar de maneira a aumentar o limite existente?

Sugestões como: otimize o código, utilize jsp include etc... nao resolvem o problema, pois o usuário tem posse da ferramenta em questão podendo dar manutenção ou criar novas páginas a qualquer momento.

Se esta for a única solução (alteração / otimização do código gerado), então teremos que mexer no código fonte da ferramenta e é justamente isto que não queremos.

Muito Obrigado pela ajuda.

This message was edited 1 time. Last update was at 24/03/2008 16:06:03

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ê:
http://www.velocityreviews.com/forums/t146001-reached-the-65535-bytes-limit.html

Paulo Silveira wrote: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 wrote: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.

This message was edited 1 time. Last update was at 24/03/2008 16:32:25

Paulo Silveira wrote: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.

A ferramenta é proprietária....
Ela gera um linguição.... e não tem include file neste linguição que ele gera.
A ferramenta é um compilador da linguagem X para diferentes linguagens. ASP - JSP - VB - .Net.

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.

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17539 Offline

A ferramenta é proprietária....

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.

This message was edited 3 times. Last update was at 24/03/2008 16:44:56

thingol wrote:
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!

Paulo Silveira wrote: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.

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17539 Offline

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

Paulo Silveira wrote: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!

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

Notícias, artigos e o maior fórum brasileiro sobre Java