Expressão Lambda Java 8 dentro do serviço REST não funciona

Se eu colocar uma expressão do Java 8 Lambda em um serviço REST, ela falhará. Se eu remover a expressão lambda, isso funciona. Não importa se eu uso a expressão lambda ou não. Apenas a existência do lambda é suficiente para falhar. Tudo o mais relacionado ao Java 8 parece funcionar.

Abaixo está meu código (simplificado):

@Path("finance") public class FinanceRest { @GET @Produces("text/plain") public String speak() { return "Hello world."; } private void lambdaFunction(Predicate predicate) { // Any lambda will cause problems, no matter how simple List numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9); Stream onlyOdds = numbers.stream().filter(n -> n%2 != 0); } } 

Como você pode ver no código acima, apenas a existência de uma expressão lambda causará falha. Assim que eu remover o lambda, funciona bem. O outro material do Java 8 é bom (por exemplo, o parâmetro de input “Predicate”).

A mensagem de erro que estou recebendo é: java.lang.ArrayIndexOutOfBoundsException: 25980

Eu tentei isso no Tomcat 7 e 8 usando o Java 8. Eu estou usando o material jax-rs padrão do JavaEE 6 …. em outras palavras, meu arquivo POM tem isso:

   javax javaee-web-api 6.0 provided  

Qualquer ajuda seria apreciada. Obrigado.

A mensagem de erro exata (no Glassfish 4.0 … Eu tentei o Tomcat e o Glassfish) é:

java.lang.ArrayIndexOutOfBoundsException: 52264 em org.objectweb.asm.ClassReader.readClass (ClassReader.java:2015) em org.objectweb.asm.ClassReader.accept (ClassReader.java:469) em org.objectweb.asm.ClassReader. accept (ClassReader.java:425) em org.glassfish.hk2.classmodel.reflect.Parser $ 5.on (Parser.java:362) em com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry (ReadableArchiveScannerAdapter.java:165 ) em com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries (ReadableArchiveScannerAdapter.java:127) em org.glassfish.hk2.classmodel.reflect.Parser.doJob (Parser.java:347) em org.glassfish.hk2. classmodel.reflect.Parser.access $ 300 (Parser.java:67) em org.glassfish.hk2.classmodel.reflect.Parser $ 3.call (Parser.java:306) em org.glassfish.hk2.classmodel.reflect.Parser $ 3 .call (Parser.java:295) em java.util.concurrent.FutureTask.run (FutureTask.java:266) em java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142) em java.util.concurrent. Fio PoolExecutor $ Worker.run (ThreadPoolExecutor.java:617) em java.lang.Thread.run (Thread.java:744)

Eu encontrei a solução! Eu estava usando Jersey 1.17.1. Quando eu atualizei para 2.7 funcionou. Meu arquivo pom tinha o seguinte:

  com.sun.jersey jersey-bundle 1.17.1 compile   com.sun.jersey jersey-servlet 1.17.1 compile  

Eu removi aqueles e adicionei:

  org.glassfish.jersey.containers jersey-container-servlet 2.7  

E é claro que eu tive que modificar o arquivo web.xml para ter:

  javax.ws.rs.core.Application   javax.ws.rs.core.Application /rs/*  

Agora tudo está funcionando bem. A pergunta é: Por que as expressões lambda ainda falharam quando as removi da class REST e as coloquei em uma class não-REST? Só o fato de eu estar incluindo Jersey 1.x foi suficiente para travar ao usar expressões lambda (se um serviço REST estava ou não envolvido). Mas, de qualquer forma, estou satisfeito que o projeto esteja funcionando novamente; Eu estava querendo atualizar para a versão mais recente do jax-rs & Jersey de qualquer maneira, então isso me forçou a fazê-lo (me custando várias horas de trabalho e preciso explicar ao “mestre SCRUM” por que minha estimativa está desligada (não Me inicie nesse tópico.) Agora, se eu puder descobrir por que Jersey 2 está retornando XML quando eu disse para retornar JSON, voltarei ao assunto.

Obrigado a todos pela vossa ajuda!

Jersey 1,19 é compatível com o JDK 1.8.0. Consulte a Jersey 1.19 Resumo da versão Suporte JDK8 em Jersey 1.19 Remackage ASM lib em Jersey 1.19

Por favor, remova asm-3.1.jar já que jersey-server-1.19.jar tem asm 5.0 repacked nele.

O stacktrace mostra que a class org.objectweb.asm.ClassReader.readClass dá uma exceção. Eu suponho que este é um analisador que Glassfish usa internamente.

Uma das razões pelas quais isso ocorreria é porque ele não está configurado para manipular a input fornecida corretamente. Neste caso, a input dada é uma expressão lambda e não sabe como lidar com isso.

Você precisará procurar suporte a bytecode (lambda) do Java 8 para Glassfish e Tomcat. Se não é o problema, então pode ser um bug no analisador que é usado internamente.

Eu tive que atualizar a primavera para 4.3.6.RELEASE e junit para 4.12 antes de me livrar desse erro em particular ao tentar executar um teste junit com java 1.8 depois que eu tinha introduzido lamdas.

Além de todas as outras respostas,

No meu sistema este problema ocorre no Glassfish 4.0(build 89)

Solução;

Fiz o upgrade do Glassfish to 4.1(build 13) e resolvi esse problema.