Compile of ExifTool fails

[dennis508]

Trying to compile ExifTool results in

./jperl Image-ExifTool-13.43/exiftool -ver
Compilation failed in require: Expected token OPERATOR with text ) but got LexerToken{type=IDENTIFIER, text='and'} at /C/C/dennis/Desktop/PerlOnJava-5.42.2/Image-ExifTool-13.43/lib/Image/ExifTool.pm line 4916, near "() and $dir"
JVM Stack Trace:
org.perlonjava.operators.ModuleOperators.require at ModuleOperators.java line 751
org.perlonjava.parser.StatementParser.parseUseDeclaration at StatementParser.java line 517
org.perlonjava.parser.StatementResolver.parseStatement at StatementResolver.java line 88
org.perlonjava.parser.ParseBlock.parseBlock at ParseBlock.java line 110
org.perlonjava.parser.ParseBlock.parseBlock at ParseBlock.java line 48

The offending lines are

if (length and not $self->IsDirectory($dir) and
                # don't try to create a network drive root directory
                not (IsPC() and $dir =~ m{^//[^/]*$}))

Download and unpack Image-ExifTool-13.43.tar.gz from exiftool.org.

I'm pretty weak with perl so forgive me if this is something that should not be expected to work.

[fglock]

Hi @dennis508,

Thank you for reporting this issue, and apologies for the delay in responding.

The original parsing problem you encountered (Expected token OPERATOR with text ) but got LexerToken{type=IDENTIFIER, text='and'}) has been fixed in commit 8651592.

However, after that fix, ExifTool now fails with a different error: "Method too large". This is a known limitation with PerlOnJava due to the JVM's 64KB method size limit. The issue is documented in our Feature Matrix:

🚧 Java segment size limitation: A workaround is implemented to Java 64k bytes segment limit.

ExifTool is a large and complex Perl module, and it triggers this JVM limitation. We're working on improving the workaround, but it will take some time to fully resolve.

Thank you for the bug report and for your patience!

[dennis508]

OK. Thank you. On Tuesday, December 16, 2025 at 04:24:05 AM EST, Flavio S. Glock ***@***.***> wrote: fglock left a comment (fglock/PerlOnJava#93) Hi @dennis508, Thank you for reporting this issue, and apologies for the delay in responding. The original parsing problem you encountered (Expected token OPERATOR with text ) but got LexerToken{type=IDENTIFIER, text='and'}) has been fixed in commit 8651592. However, after that fix, ExifTool now fails with a different error: "Method too large". This is a known limitation with PerlOnJava due to the JVM's 64KB method size limit. The issue is documented in our Feature Matrix: 🚧 Java segment size limitation: A workaround is implemented to Java 64k bytes segment limit. ExifTool is a large and complex Perl module, and it triggers this JVM limitation. We're working on improving the workaround, but it will take some time to fully resolve. Thank you for the bug report and for your patience! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[fglock]

ExifTool Status Update

Hi @dennis508,

Following up on the ExifTool compilation issue from three weeks ago.

Current Status

Since the initial parsing fix in commit 8651592, additional work has been done to address various compilation and runtime issues. Testing with ExifTool 13.44 shows the following results:

Working Functionality

Basic metadata extraction from images is now operational:

• Reading EXIF data from JPEG files
• Extracting specific tags (Make, Model, DateTimeOriginal, etc.)
• Multiple output formats: standard, short format (-s), tab-delimited (-T)
• Group names display (-G, -G1)
• Numeric values (-n)
• Common tags extraction (-common)
• Fast mode (-fast)
• Recursive directory processing (-r)

Example working commands:

JPERL_LARGECODE=refactor ./jperl -Ilib exiftool -ver
JPERL_LARGECODE=refactor ./jperl -Ilib exiftool t/images/GPS.jpg
JPERL_LARGECODE=refactor ./jperl -Ilib exiftool -Make -Model t/images/Ricoh2.jpg

Remaining Issues

Several features still encounter the "Method too large" compilation error:

• JSON output format (-json)
• CSV output format (-csv)
• Processing certain specific image files
• Advanced help display (-h)
• Some listing commands (-listx)
• Vendor-specific modules (Nikon, FLIR)

Additionally, some subroutines remain undefined:

• -list (GetAllTags)
• -listw (GetWritableTags)
• -listd (GetDeleteGroups)

Write operations are not yet functional.

Technical Details

The "Method too large" errors occur at specific locations:

• ExifTool.pm:3738 (affects JSON/CSV output and some images)
• Various anonymous subroutines in the main exiftool script

These continue to be related to the JVM's 64KB method size limitation mentioned in the Feature Matrix.

[dennis508]

Thanks for the update. Happy New Year! Is there documentation on the 64K workaround or even just a key source file to help me understand how it works? Thanks.

[fglock]

Thanks for the question! Happy New Year to you too!

Overview

The 64K workaround addresses the JVM's method size limit (64KB of bytecode per method). When we detect that generated bytecode would exceed this limit, we automatically split the code into smaller subroutines.

How It Works

Before split (original code >64K):

A; B; C; D; E; F;

After split (each chunk ~32K):

A; B; C; sub { D; E; F }->(@_);

The large code block is refactored into smaller anonymous subroutines while preserving functionality.

The Challenge: Control Flow Operators

The main complexity arises with control flow operators like next, last, and redo, which are used extensively in tools like ExifTool.

The problem: Not all refactorings are valid:

• The JVM doesn't support goto into a subroutine
• We can't naively split a for loop that contains next or last

The solution: Perl does support next from within a subroutine to an outer loop, so we're "rewiring" the bytecode emitter to handle this control flow pattern. The technical challenge is ensuring all control flow operations maintain consistent stack states, as required by the JVM bytecode verifier.

Current Status

Active development is happening in the fix-control-flow-tagged-returns branch.

Note: This branch is not ready for production yet. We're making significant changes to stack handling, including replacing stack operations with local variables to ensure control flow targets are compatible. This work needs to be thoroughly tested before it can be merged.