Java 8 Lambda-Ausdrücken Innerhalb von REST-Dienst nicht funktioniert

Wenn ich ein Java 8 Lambda-Ausdruck in einen REST-Dienst, stürzt es ab. Wenn ich entfernen Sie die lambda-Ausdruck, es funktioniert. Es spielt keine Rolle, wenn ich den lambda-Ausdruck oder nicht. Nur die Existenz der lambda ist genug, zum Absturz zu bringen. Alles andere Java 8 Verwandte arbeiten scheint.

Unten ist mein code (stark vereinfacht):

@Path("finance")
public class FinanceRest {

    @GET
    @Produces("text/plain")
    public String speak() {
        return "Hello world.";
    }

    private void lambdaFunction(Predicate<Account> predicate) {
        //Any lambda will cause problems, no matter how simple
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);
        Stream<Integer> onlyOdds = numbers.stream().filter(n -> n%2 != 0);
    }

}

Wie Sie sehen können aus dem obigen code, nur die Existenz eines lambda-Ausdrucks werden die Fehler verursachen. Sobald ich entfernen Sie die lambda, es funktioniert gut. Die anderen Java-8 Zeug in Ordnung ist (zum Beispiel das "Prädikat" input-parameter).

Die Fehlermeldung, die ich bekomme ist:
java.lang.ArrayIndexOutOfBoundsException: 25980

Ich habe versucht, diese auf Tomcat 7 und 8, die mit Java 8.
Ich bin mit dem standard jax-rs Zeug von Java ee 6.... in anderen Worten meine POM-Datei diese:

    <dependency>
        <groupId>javax</groupId>
        <artifactId>javaee-web-api</artifactId>
        <version>6.0</version>
        <scope>provided</scope>
    </dependency>

Jede Hilfe würde geschätzt werden.
Danke.

Die genaue Fehlermeldung (auf Glassfish 4.0... ich habe versucht, sowohl Tomcat und Glassfish):

java.lang.ArrayIndexOutOfBoundsException: 52264 an
org.objectweb.asm.ClassReader.readClass(ClassReader.java:2015)
org.objectweb.asm.ClassReader.akzeptieren(ClassReader.java:469) at
org.objectweb.asm.ClassReader.akzeptieren(ClassReader.java:425) an
org.glassfish.hk2.classmodel.reflektieren.Parser,$5.auf(Parser.java:362) at
com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:165)
bei
com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:127)
bei org.glassfish.hk2.classmodel.reflektieren.Parser.doJob(Parser.java:347)
bei
org.glassfish.hk2.classmodel.reflektieren.Parser.Zugriff auf$300(Parser.java:67)
bei
org.glassfish.hk2.classmodel.reflektieren.Parser,$3.call(Parser.java:306)
bei
org.glassfish.hk2.classmodel.reflektieren.Parser,$3.call(Parser.java:295)
bei java.util.gleichzeitige.FutureTask.run(FutureTask.java:266) at
java.util.gleichzeitige.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
bei
java.util.gleichzeitige.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
bei java.lang.Thread.run(Thread.java:744)

Ich hasse es zu sagen, dass es klingt wie ein bug, aber es funktioniert. Nur das hinzufügen eines lambda-Ausdrucks sollte nicht brechen JAX-RS-Implementierungen.
Sie verwenden müssen, Tomcat 8, nicht 7. Stellen Sie sicher, dass JAVA_HOME wies auf die Java8 JRE, tomcat so wird es abholen. Other than, die ich bin mir nicht wirklich sicher, was das Problem sein könnte.
Java 8 läuft auf Tomcat 7 als gut. Ich habe eine Instanz die Ausführung von Java 8 ohne Probleme. Nur stellen Sie sicher, dass die version 7.52+ (glaube ich)
Sind Sie die neuen Java-8-bytecode-Konstrukte? (Lambda, etc.)
Können Sie nach dem vollständigen stacktrace des Fehlers?

InformationsquelleAutor David Jensen | 2014-04-07

  1. 26

    Ich die Lösung gefunden!
    Ich war mit Jersey-1.17.1. Wenn ich ein Upgrade auf 2.7 hat es geklappt. Meine pom-Datei waren die folgenden:

    <dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey-bundle</artifactId>
    <version>1.17.1</version>
    <scope>compile</scope>
</dependency>

<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey-servlet</artifactId>
    <version>1.17.1</version>
    <scope>compile</scope>
</dependency>

    Ich entfernt und Hinzugefügt:

    <dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <artifactId>jersey-container-servlet</artifactId>
    <version>2.7</version>
</dependency>

    Und natürlich musste ich das ändern web.xml Datei:

    <servlet>
    <servlet-name>javax.ws.rs.core.Application</servlet-name>
</servlet>

<servlet-mapping>
    <servlet-name>javax.ws.rs.core.Application</servlet-name>
    <url-pattern>/rs/*</url-pattern>
</servlet-mapping>

    Nun alles gut funktioniert. Die Frage ist: Warum wurden lambda-Ausdrücke noch immer nicht, wenn ich entfernt, die Sie vom REST der Klasse und setzen Sie Sie in einem nicht-REST der Klasse? Nur die Tatsache, ich war auch Jersey 1.x war genug, um Absturz bei der Verwendung von lambda-Ausdrücken (ob oder nicht auf einen tatsächlichen REST-Dienst beteiligt war). Aber jedenfalls, ich bin froh, dass das Projekt funktioniert wieder; ich hatte gefehlt, um ein upgrade auf die neueste version von jax-rs & Jersey sowieso, so dass dies mich gezwungen, es zu tun (es kostet mich einige Stunden Arbeit und müssen zu erklären, "SCRUM master", warum meine Einschätzung ist " aus "(don ' T get me started auf das Thema). Wenn ich jetzt nur herausfinden, warum Jersey 2 ist die Rückgabe von XML -, als ich sagte, es zu JSON zurückgeben werde ich wieder auf die Strecke.

    Danke an alle für Eure Hilfe!

    InformationsquelleAutor David Jensen

  2. 12

    Jersey 1.19 ist kompatibel mit JDK 1.8.0. Finden
    Jersey 1.19 Release-ZusammenfassungJDK8 Unterstützung in Jersey 1.19Packen Sie die ASM-lib in Jersey 1.19

    Bitte entfernen asm-3.1.jar da jersey-server-1.19.jar hat asm 5.0 umgepackt.

    InformationsquelleAutor Tom Shen

  3. 3

    Der stacktrace zeigt, dass die Klasse org.objectweb.asm.ClassReader.readClass gibt eine Ausnahme. Ich vermute, das ist ein parser, der Glassfish-intern verwendet.

    Einer der Gründe, warum es zum Absturz, weil es nicht konfiguriert ist zum verarbeiten des gegebenen input richtig. In diesem Fall wird der Eingang ist ein lambda-Ausdruck, und es nicht weiß wie es zu handhaben.

    Werden Sie brauchen, um für die Java-8-bytecode (lambda) - support für Glassfish und Tomcat. Wenn es nicht das Problem, dann könnte es ein bug im parser intern verwendet.

    InformationsquelleAutor skiwi

  4. 1

    Hatte ich ein upgrade Frühling bis 4.3.6.RELEASE-und junit-4,12 bevor ich entledigte sich dieser spezielle Fehler beim ausführen eines junit test mit java 1.8 nachdem ich Sie eingeführt hatte, lamdas.

    InformationsquelleAutor David B

  5. 0

    Zusätzlich zu allen anderen Antworten,

    Auf meinem system dieses problem ist aufgetreten auf Glassfish 4.0(build 89)

    Lösung;

    Aktualisiert ich Glassfish to 4.1(build 13) und es löste das problem.

    InformationsquelleAutor Yusuf K.

Schreibe einen Kommentar