Add --ignore-manifest flag to skip problematic manifest attributes

[maxandersen]

Context

As discussed in PR #2439, JBang now honors more JAR manifest attributes like Enable-Native-Access, Add-Opens, and Add-Exports. This brings JBang closer to java -jar behavior, but also means that broken or incompatible manifest attributes could prevent JARs from running.

Use Case

Users may encounter third-party JARs with:

• Malformed manifest attributes they cannot fix (closed-source JARs)
• Attributes that fail validation on newer Java versions but would work on older versions
• Experimental or non-standard attributes that cause issues

Currently, users have limited workarounds and may be blocked from running otherwise functional JARs.

Proposed Solution

Add a --ignore-manifest flag that allows users to skip specific manifest attributes:

# Ignore a single attribute
jbang --ignore-manifest=Enable-Native-Access run broken.jar

# Ignore multiple attributes
jbang --ignore-manifest=Enable-Native-Access,Add-Opens run broken.jar

Implementation Notes

• Should work as an escape hatch for any manifest attribute JBang reads
• Could accept comma-separated list of attribute names
• Attributes that are ignored should be completely skipped (not passed to JVM)
• Could potentially add a warning when attributes are ignored

Alternatives Considered

• Always validate strictly: too restrictive, goes against "make Java easy" philosophy
• Always pass through without validation: current approach, but no escape hatch for broken JARs

This flag provides the best of both worlds: honor manifest attributes by default, but give users control when needed.

Related

• PR fix(run): honor manifest launcher flags #2439 - implements reading of Enable-Native-Access, Add-Opens, Add-Exports
• Issue jbang run <jarFile> ignores Enable-Native-Access property in the manifest.mf file #2366, jbang run <jarFile> ignores Add-Opens property in the MANIFEST.MF file #2438 - original issues about manifest handling

[wfouche]

I'm wondering if using -XX:+IgnoreUnrecognizedVMOptions could be an alternative stop gap solution?

I discovered today the this option has a related option called -XX:+IgnoreUnrecognizedXXColonOptions.

The first option was used to get the JVM to ignore a MacOS specific option -XstartOnFirstThread that caused the JVM to not start on Linux or WIndows. Just thought it might work here as well.

[wfouche]

Currently, users have limited workarounds and may be blocked from running otherwise functional JARs.

Do you have concrete examples of where this becomes an issue, or are you anticpating that issues might occur and are proposing this workaround?

[ayagmar]

Hey @maxandersen
I've been workin on this one as a followup on and off.. I have a few ideas for cleaning it up but there's something I want to confirm regarding contracts
Basically the issue examples includes using jbang --ignore-manifest=... run broken.jar, which means touching Main.handleDefaultRun()
I’m fine doing that, but I wanted to double check and verify with you whether you want that top-level form specifically, or whether jbang run --ignore-manifest=... would also be acceptable
Thanks!

[maxandersen]

It's only relevant for running I think so having it after run is fine.

But that said - as Werner asks - got any examples where this is actually a problem ? Because even if simple to implement it's a lot of complexity to introduce for something that is only theoretically a problem.