1. aspectjweaver-1.8 13 jar invalid cen header (invalid zip64 extra data field size)

The aspectjweaver-1.8.13.jar (and similar older versions like 1.8.9) fails with an "Invalid CEN header (invalid zip64 extra data field size)" error when used with modern JDK versions (JDK 11.0.20+, 17.0.8+, 21, and 22+). This is caused by stricter ZIP64 validation checks introduced by Oracle to prevent security vulnerabilities and ensure adherence to the ZIP specification. 

To resolve this issue, use one of the following solutions:

• Upgrade AspectJ: The recommended fix is to upgrade to a newer version of AspectJ (e.g., AspectJ 1.9.22.1 or later) that was packaged using tools compliant with the new validation rules.
• Apply JVM Workaround: You can temporarily disable the strict validation by adding the following flag to your application's startup arguments or Maven/IDE configuration:
  -Djdk.util.zip.disableZip64ExtraFieldValidation=true
  This can be set in environment variables like JAVA_TOOL_OPTIONS or within an application server's setenv file.
• Downgrade JDK: If an upgrade is not possible, switching back to an older JDK build (e.g., JDK 11.0.19 or earlier) that does not include the JDK-8302483 patch will stop the error.
• Clean Maven Repository: In some cases, the JAR may be corrupted. Try deleting the org/aspectj/aspectjweaver/1.8.13 directory from your local .m2/repository and re-running your build to force a fresh download. 

2. 配置好idea的jdk后，terminl上运行mvn clean install，报错：

cannot find symbol [ERROR] symbol: variable log

In JDK 25 and other modern Java versions (21+), the Maven error cannot find symbol: variable log is typically caused by Lombok not being compatible with the newer compiler or lacking the required annotation processing configuration. 

Core Fixes

• Enable Stricter Annotation Processing: Starting from JDK 23, you must explicitly enable full annotation processing. Add the <compilerArgs> flag to your maven-compiler-plugin configuration in pom.xml:

  xml

  <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
          <compilerArgs>
              <arg>-proc:full</arg>
          </compilerArgs>
      </configuration>
  </plugin>
  

• Explicitly Define Annotation Processor Path: Ensure Lombok is defined in the annotationProcessorPaths section of the maven-compiler-plugin:

  xml

  <configuration>
      <annotationProcessorPaths>
          <path>
              <groupId>org.projectlombok</groupId>
              <artifactId>lombok</artifactId>
              <version>1.18.34</version> <!-- Use the latest version for JDK 25 support -->
          </path>
      </annotationProcessorPaths>
  </configuration>
  

   

3. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project api: Fatal error compiling: java.lang.ExceptionInInitializerError: com.sun.tools.javac.code.TypeTag :: UNKNOWN

The error java.lang.ExceptionInInitializerError: com.sun.tools.javac.code.TypeTag :: UNKNOWN typically occurs when you use an outdated version of Lombok with a newer version of the Java Development Kit (JDK). 

This specific TypeTag :: UNKNOWN or TypeTags error is triggered because Lombok relies on internal javac APIs that frequently change in newer JDK releases. When Lombok fails to find a specific field (like UNKNOWN) via reflection, it throws this initialization error. 

Immediate Solutions

• Update Lombok: The most common fix is to update your project's Lombok dependency to the latest version.
  • For JDK 24, you must use Lombok 1.18.38 or higher.
  • For JDK 25, you may need to check for even newer releases or snapshots.
  • Update your pom.xml (Maven) or build.gradle (Gradle) with the latest version from the Project Lombok website.
• Check JDK Compatibility: Ensure your JAVA_HOME and project language levels match.
  • If you are running an older project (e.g., Java 8) but your system's default JDK is Java 11+, either update the project's dependencies or switch your IDE's Project SDK and JAVA_HOME back to Java 8.
• Update Maven Compiler Plugin: Sometimes the maven-compiler-plugin version is too old to handle the newer JDK's internal changes. Ensure you are using version 3.10.1 or newer. 

Summary Checklist

1. Update Lombok: Change version to >= 1.18.38 in your build file.
2. Verify Java Version: Ensure your project's target JDK version is supported by your current Lombok version.
3. Set Compiler Configuration: If using Maven, ensure the release or source/target flags are correctly set for your JDK. 

4. dubbo报错：

dubbo Can't create adaptive extension interface org.apache.dubbo.rpc.Protocol, cause: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang"

This error occurs because you are running Apache Dubbo on Java 17 or higher. Starting with JDK 16, Java's module system enforces strong encapsulation, which blocks Dubbo's internal bytecode generator from reflectively accessing ClassLoader.defineClass. 

To fix this, you must explicitly allow access to the java.lang package by adding a JVM argument to your application's startup command. 

Solution: Add JVM Startup Argument 

Add the following flag to your java execution command:

--add-opens=java.base/java.lang=ALL-UNNAMED

Implementation by Environment

• Command Line / Shell Script:
  Include the flag directly in your start command before the -jar or main class:
  java --add-opens=java.base/java.lang=ALL-UNNAMED -jar your-dubbo-app.jar
• IntelliJ IDEA:
  1. Go to Run | Edit Configurations....
  2. Select your application.
  3. Click Modify options -> Add VM options.
  4. Paste --add-opens=java.base/java.lang=ALL-UNNAMED into the box.
• Maven (for Unit Tests):
  Add the configuration to the Maven Surefire Plugin in your pom.xml:

  xml

  <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <configuration>
          <argLine>--add-opens=java.base/java.lang=ALL-UNNAMED</argLine>
      </configuration>
  </plugin>
  

  Use code with caution.

• Gradle (for Unit Tests):
  Add the following to your test block in build.gradle:

  gradle

  test {
      jvmArgs '--add-opens', 'java.base/java.lang=ALL-UNNAMED'
  }
  

  Use code with cauti

Note: Using the latest stable version of Dubbo (3.x) often improves compatibility, but these --add-opens flags remain the standard workaround for bytecode-heavy frameworks on modern JDKs.