search

leibnitz27 / cfr

This is the public repository for the CFR Java decompiler
https://www.benf.org/other/cfr
MIT License
1.93k stars 249 forks source link

Module dumping improvements #287

Closed Marcono1234 closed 2 years ago

Marcono1234 commented 2 years ago

Example:

module test {
    requires static java.sql;

    uses java.util.List;
}

Compile with javac --module-version=99 .\module-info.java.

Output:

/*
 * Decompiled with CFR 0.153-SNAPSHOT (a260598).
 */
import java.util.List;

open module test {
    // version: 99

    requires static java.sql /* version: 17 */;

    uses List;

}
leibnitz27 commented 2 years ago

I'm trying to think of a clean way of testing multiple module specs in current cfrtest project - any improvement on adding a bunch of top level source dirs and then including them in every j14+ build?

On Wed, 26 Jan 2022, 18:49 Marcono1234, @.***> wrote:

  • Properly dumps requires static (instead of including / static phase /)
  • Dumps uses directives (they were missing before)
  • Dumps information about module versions as comments, if present

Example:

module test { requires static java.sql;

uses java.util.List;

}

Compile with javac --module-version=99 .\module-info.java.

Output:

/ Decompiled with CFR 0.153-SNAPSHOT (a260598). */import java.util.List;

open module test { // version: 99

requires static java.sql /* version: 17 */;

uses List;

}

You can view, comment on, or merge this pull request online at:

https://github.com/leibnitz27/cfr/pull/287 Commit Summary

File Changes

(2 files https://github.com/leibnitz27/cfr/pull/287/files)

Patch Links:

— Reply to this email directly, view it on GitHub https://github.com/leibnitz27/cfr/pull/287, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFXCEAEICFYE66GCRBZ4JLUYA643ANCNFSM5M32JDIA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

leibnitz27 commented 2 years ago

\o/ thanks!

Marcono1234 commented 2 years ago

I'm trying to think of a clean way of testing multiple module specs in current cfrtest project - any improvement on adding a bunch of top level source dirs and then including them in every j14+ build?

Not really. Is that even possible or does Maven then complain about too many module declarations?

One really hacky solution might be to specify multiple Maven Compiler Plugin executions each with different inclusions for module-info.java files, and then passing the javac -d option to specify a custom output directory, e.g.:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.9.0</version>
  <configuration>
    <includes>
      <!-- Specify no include for default compile -->
      <include></include>
    </includes>
  </configuration>
  <executions>
    <execution>
      <id>compile1</id>
      <goals>
        <goal>compile</goal>
      </goals>
      <configuration>
        <includes>
          <include>first/module-info.java</include>
        </includes>
        <compilerArgs>
          <arg>-d</arg>
          <arg>custom-out</arg>
        </compilerArgs>
      </configuration>
    </execution>
    <execution>
      <id>compile2</id>
      <goals>
        <goal>compile</goal>
      </goals>
      <configuration>
        <includes>
          <include>second/module-info.java</include>
        </includes>
        <compilerArgs>
          <arg>-d</arg>
          <arg>custom-out2</arg>
        </compilerArgs>
      </configuration>
    </execution>
  </executions>
</plugin>

But I wouldn't be surprised if that breaks in the future.

Maybe including the compiled module descriptors in the hardcoded folder of cfr_tests would be fine as well?