You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@freemarker.apache.org by "Dániel Dékány (Jira)" <ji...@apache.org> on 2025/01/14 19:28:00 UTC

[jira] [Comment Edited] (FREEMARKER-229) Add GraalVM native support for Apache FreeMarker

    [ https://issues.apache.org/jira/browse/FREEMARKER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17913037#comment-17913037 ] 

Dániel Dékány edited comment on FREEMARKER-229 at 1/14/25 7:27 PM:
-------------------------------------------------------------------

We can include the additional meta-information, that's fine. Though, then it would be good to also be able test if it still works before releases. Maybe that's not feasible to do automatically (esp. with Github Action), but at least it should be added as a manual step to manual pre-release process.

You say Java 11 is needed for that annotation, be we can include Java 11 class files files via "JEP 238: Multi-Release JAR Files". We already do that for multiple Java versions. Does that work with the GaalVM Native compiler?

Also, in that replacement class you return false for the question "Should we just use SLF4J instead of Log4J API?". That SLF4J smoke test that you had to replace is a backward compatibility "paranoia" thing in FreeMarker. But that level of backward compatibility is not applicable to GraalVM Native applications, as there's almost none out there that relies on FreeMarker, and those knowingly take a risk, as they had to patch FreeMarker. So we can say that under GraalVM Native, if SLF4J API classes are present, then we just use that "blindly", like any other normal library does it. It can even have priority over the other logging frameworks, in the case of GraalVM Native. Given that you can modify the existing FreeMarker classes (via PR), I hope there's some easy way to detect that we are in GraalVM Native, and then we can put that logic directly into the freemarker.log.Logger auto-detection.


was (Author: ddekany):
We can include the additional meta-information, that's fine. Though, then it would be good to also be able test if it still works before releases. Maybe that's not feasible to do automatically (eps. with Github Action), but at least it should be added as a manual step to manual pre-release process.

You say Java 11 is needed for that annotation, be we can include Java 11 class files files via "JEP 238: Multi-Release JAR Files". We already do that for multiple Java versions. Does that work with  the GaalVM Native compiler?

Also, in that replacement class you return false for the question "Should we just use SLF4J instead of Log4J API?". Than SLF4J smoke test that you had to replace is a backward compatibility "paranoia" thing in FreeMarker. But that level of backward compatibility is not applicable to GraalVM Native applications, as there's almost none out there that relies on FreeMarker, and is not knowingly takes a risk, as they had to patch FreeMarker for that. So we can say that under GraalVM Native, if SLF4J API is present, then we just use that "blindly", like any other normal library does it. It can even have priority over the other logging frameworks, in the case of GraalVM Native. Given that you can modify the existing FreeMarker classes (via PR), I hope there's some easy way to detect that we are in GraalVM Native, and then we can put that logic directly into the freemarker.log.Logger auto-detection.

> Add GraalVM native support for Apache FreeMarker
> ------------------------------------------------
>
>                 Key: FREEMARKER-229
>                 URL: https://issues.apache.org/jira/browse/FREEMARKER-229
>             Project: Apache Freemarker
>          Issue Type: New Feature
>            Reporter: Matteo Franci
>            Priority: Minor
>
> First of all I want to thank you for the great work on Apache FreeMarker. The team I work with and I have been using on many projects.
> As we are using more and more GraalVM native applications in our team, It would be nice to have some sort of built-in support.
> Currently I only found a community support on [GraalVM reachbility metadata.|https://github.com/oracle/graalvm-reachability-metadata/blob/master/metadata/org.freemarker/freemarker/index.json]
> So I created a github repo we are using to add GraalVM support to projects : 
> [https://github.com/fugerit-org/freemarker-native]
> NOTE: main limitations is that requires java 11+ because of [GraalVM SDK Substitute Annotation|https://www.graalvm.org/sdk/javadoc/com/oracle/svm/core/annotate/Substitute.html]. this is needed to fix missing org.apache.log4j.MDC class in  [https://github.com/apache/freemarker/blob/v2.3.34/freemarker-core/src/main/java/freemarker/log/_Log4jOverSLF4JTester.java#L35]
> I had a look at the main repository : 
> [https://github.com/apache/freemarker/tree/2.3-gae]
> And maybe it is possible to include all the necessary changes in it, or build a "native support" module, alongside the main distribution.
> What do you think?
> If I can help you anyway I'm here.
> Thanks in advance.
> NOTE: here you can find more details on how GraalVM support has been added [https://github.com/fugerit-org/freemarker-native/blob/main/src/main/docs/native-support/index.adoc] .



--
This message was sent by Atlassian Jira
(v8.20.10#820010)