title: AWS Lambda using incorrect classfiles from a Multi-Release JAR?
body: <p>I've had a lambda running for a few years under Java8, and I just updated it to Java 11. It immediately broke, giving me errors like:</p>
  <pre><code>Caused by: java.lang.ExceptionInInitializerError
      at com.mycompany.rest.providers.JsonProvider.writeTo(JsonProvider.java:80)
      at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:242)
      at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:227)
      at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:139)
      at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1116)
      at org.glassfish.jersey.client.ClientRequest.doWriteEntity(ClientRequest.java:461)
      at org.glassfish.jersey.client.ClientRequest.writeEntity(ClientRequest.java:443)
      at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:367)
      at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:265)
      at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:297)
      ... 15 more
  Caused by: java.lang.UnsupportedOperationException: No class provided, and an appropriate one cannot be found.
      at org.apache.logging.log4j.LogManager.callerClass(LogManager.java:571)
      at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:596)
      at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:583)
      at com.mycompany.rest.util.NonClosingOutputStream.&lt;clinit&gt;(NonClosingOutputStream.java:11)
      ... 25 more
  </code></pre>
  <p>The class in question isn't particularly exciting, and has a straightforward static initialization that is common in my classes:</p>
  <pre><code>public class NonClosingOutputStream extends ProxyOutputStream {
      private static final Logger log = LogManager.getLogger(); // Line 11
  
      public NonClosingOutputStream(final OutputStream proxy) {
          super(proxy);
      }
  
      ...
  </code></pre>
  <p>I've <em>seen</em> problems like this before, when I switched my (non-Lambda) java servers from 8 to 11; I needed to flag my jar's manifest as <code>Multi-Release: true</code>, because the ApacheLog4j artifact that I depend on provides alternate implementations for the <code>org.apache.logging.log4j.util.StackLocator</code> class in Java 8- and 9+. However, I kind of expect the JVM to just pick up the appropriate version of the class. Is there some configuration that I have to set somewhere? Is it possible that switching my Lambda from Java 8 -&gt; Java 11 <em>confused</em> something, somewhere?</p>
  <p><code>jar/META-INF/versions:</code></p>
  <pre><code>versions/
  ├── 11
  │   └── org
  │       └── glassfish
  │           └── jersey
  │               └── internal
  │                   └── jsr166
  │                       ├── JerseyFlowSubscriber$1.class
  │                       ├── JerseyFlowSubscriber.class
  │                       ├── SubmissionPublisher$1.class
  │                       ├── SubmissionPublisher$2.class
  │                       ├── SubmissionPublisher$3.class
  │                       ├── SubmissionPublisher$4.class
  │                       ├── SubmissionPublisher$5.class
  │                       ├── SubmissionPublisher$6.class
  │                       ├── SubmissionPublisher.class
  │                       └── SubmissionPublisherFactory.class
  └── 9
      ├── module-info.class
      └── org
          └── apache
              └── logging
                  └── log4j
                      ├── core
                      │   └── util
                      │       └── SystemClock.class
                      └── util
                          ├── Base64Util.class
                          ├── ProcessIdUtil.class
                          ├── StackLocator.class
                          └── internal
                              └── DefaultObjectInputFilter.class
  </code></pre>
  <p><strong>Edit:</strong> I am finding <a href="https://stackoverflow.com/questions/35639561/aws-lambda-access-to-meta-inf-manifest-mf">some references</a> indicating that, when AWS Lambda extracts a JAR, they don't extract the META-INF directory, which contains the MANIFEST.MF file that tells the JVM that the JAR is a Muli-Release JAR. Do Lambdas support Multi-Release JARs at all?</p>