[tool](fe) add fast-compile-fe.sh for incremental FE compilation

[englefly]

Add tools/fast-compile-fe.sh, a developer utility that incrementally compiles only changed Java source files and patches them directly into doris-fe.jar, avoiding a full Maven rebuild during development.

Key features:

• Auto-detects stale .java files by comparing mtime with .class files
• Supports explicit file arguments (by path or filename search under src/)
• Caches the classpath derived from target/lib to skip repeated mvn calls
• Updates both target/doris-fe.jar and output/fe/lib/doris-fe.jar
• Handles inner classes and anonymous classes (e.g. Foo$Bar.class)

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[englefly]

run buildall

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.

[englefly]

run buildall

[englefly]

run buildall

[morrySnow]

/review

[github-actions]

Code Review Summary: tools/fast-compile-fe.sh

This PR adds a developer utility script for incremental FE compilation. The script is well-structured and useful. A few issues and suggestions below.

Critical Checkpoint Conclusions

• Goal/correctness: The script achieves its stated goal of incremental compilation for fe-core. However, it only covers fe/fe-core while the FE has many sub-modules (fe-common, fe-catalog, fe-foundation, fe-type, etc.). Changes in those modules won't be picked up. This scope limitation should be clearly documented.
• Modification minimal/focused: Yes, single new file, well-scoped.
• Concurrency: N/A (shell script, single-threaded).
• Lifecycle/static init: N/A.
• Configuration items: N/A.
• Incompatible changes: N/A — dev tool only, no production impact.
• Parallel code paths: N/A.
• Special conditional checks: The stale-file detection only checks mtime of the main .class file, not inner classes. If only an inner class is stale (e.g., due to a dependency change), it won't be detected. Acceptable trade-off for a dev tool.
• Test coverage: No automated tests, which is fine for a developer utility script.
• Observability: Colored info/warn/error output is adequate.
• Performance: The find_stale_java_files function spawns one shell loop over all .java files in SRC_ROOT. For large source trees this is slow; a find ... -newer approach or rsync --dry-run would be faster, but acceptable for a dev tool.

Issues Found

1. (Medium) javac -source 8 -target 8 differs from the Maven build's <release>8</release>. The --release flag restricts API usage to the target JDK's boot classpath; -source/-target does not. This means the fast-compile path could successfully compile code that uses JDK 17+ APIs, which would then fail in the real Maven build. Consider using --release 8 instead.

2. (Medium) collect_updated_classes uses ${java_file#$SRC_ROOT/} to compute class file paths. If a user passes a file that is not under SRC_ROOT (e.g., a generated-sources file, or a file resolved from a different module), the prefix stripping is a no-op and the resulting class path will be completely wrong, silently producing no matches.

3. (Low) The trap "rm -f $tmpfile" EXIT on line 200 replaces any prior EXIT trap. Currently there is no prior trap so this is benign, but it's fragile for future edits. Consider using a single top-level cleanup function.

4. (Low) xargs jar uf on lines 211/217 splits on whitespace by default. If any class file path contains spaces, this will break. Use xargs -d '\n' (GNU xargs) for safety.

5. (Info) The script only supports fe/fe-core. The usage header and help text should mention this explicitly, since developers editing fe-common or fe-catalog might expect this tool to handle those modules too.

[morrySnow]

source and target read from pom.xml is better?

[englefly]

run buildall

[hello-stephen]

BE UT Coverage Report

Increment line coverage 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	53.06% (20162/37995)
Line Coverage	36.65% (189848/518073)
Region Coverage	32.90% (147430/448075)
Branch Coverage	34.03% (64528/189612)