Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/Azure/Azure-Functions/issues/1991 below:

Java 8 stop supporting loading the worker jars · Issue #1991 · Azure/Azure-Functions · GitHub

Currently the default for the java worker is loading the java worker jars first then loading the customer jars. This was the solution to not make any break change after shading the java worker jars (note the gson jar is the only one that is not shaded).
The jars is uploaded at https://github.com/Azure/azure-functions-java-worker/tree/dev/lib_worker_1.6.2
There is around 32 jars in the folder.

To switch the order the customer needs to add the application setting FUNCTIONS_WORKER_JAVA_LOAD_APP_LIBS True or 1
Azure/azure-functions-java-worker#381

Note: the jars that loaded first takes presence.

The default jars are on old versions and we do not support any upgrades.

There is no evidence or numbers that we can know how much of the customer will get impacted. All java 8 users will get the change. The apps will break is the ones the application depends on any of the mentioned 32 jars and the customer did not add them to be part of their app deployment.

We will not add compact-mode support

Can we detect that a customer is using this when they upgrade from v3? Is there a specific error that can be thrown with a link to migration guidance?
Yes the exception will be class not found exception.

The support team needs to be informed in case the customer app failed to start and guide them for which package it is missing and ask the customer to deploy and upload it.

We may need to document the new behavior of Java worker and deprecate the issue Azure/azure-functions-java-worker#381

Java worker

No expected perf impact.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4