Are TypeTables / classpath.tsv.gz automatically loaded?

[mensinda]

Hi,

I am currently writing a custom Recipe and have generated a classpath.tsv.gz TypeTable for my dependencies. However, at least for the tests, I have to manually register / add it with classpathFromResources for my test:

    @Override
    public void defaults(RecipeSpec spec) {
        spec
            .recipeFromResource("/META-INF/rewrite/tupstdmid-log.yml", "tup.std.rewrite.log.refactor_7_1")
            .parser(JavaParser.fromJavaVersion().classpathFromResources(new InMemoryExecutionContext(), "tupstdmid-log-api"));
    }

Is something like this also required once the rewriter is executed in production mode? Or will all classes from classpath.tsv.gz be loaded automatically?

[timtebeek]

hi! When you use JavaTemplate, or when you provide test text blocks, those are snippets get compiled in complete isolation from your project classpath. This is to allow multiple major versions of libraries to be used within a single recipe module, but does then indeed require that you construct a JavaParser, and provide it with the entries it should place on the classpath (and any imports) when you compile the provided snippets.

For your tests the above pattern already looks correct to me (maybe add a version suffix such as tupstdmid-log-api-1); for your main code you'll similarly want to use classpathFromResources but provide it with the ExecutionContext instance that's already passed into your visitor, not a new instance, to take advantage of loading and caching optimalizations.

Hope that helps you there!

[mensinda]

Also, how does openrewrite handle multiple versions of the same dependency? Are the classes merged together?

So if v1 of the lib has:

public class A {
    public int foo() { return 42; }
}

and v2 has:

public class A {
    public int bar() { return 21; }
}

(and both libs are loaded into the TypeTables), is the internal model of openrewrite then:

public class A {
    public int foo() { return 42; }
    public int bar() { return 21; }
}

[timtebeek]

So in your case you're manually crafting LST elements through their constructor; that's a bit clunky and could break if we add fields. JavaTemplate was added to make that easier: compile a snippet of code and insert it as needed. If you don't use JavaTemplate, you likely also don't need type tables.

As for how we handle multiple versions, that's best explained here: https://docs.openrewrite.org/authoring-recipes/multiple-versions

[mensinda]

Thanks for the tip with the JavaTemplate, I will try that.

---

Regarding the multiple versions, what I was concerned about is how exactly multiple versions with the TypeTables work. Specifically for maven projects. At least from what I understand, the doc describes the problem and how it can be solved in tests, but not really how this is handled at runtime. It is documented in great detail how a classpath.tsv.gz can be generated, but not how it is to be used, or how it works (when is it loaded, how are the different library versions handled, etc.).

What I am mostly concerned about is that I have another module with a breaking change where: The class is renamed and I also wan't to rename a method. Doesn't openrewrite need the type information for both library versions (to build the LST for both the old Java code with the old library and then the LST for the new Java code with the new library)?

[timtebeek]

That'll work; typically you'd have separate recipes for different changes across major versions, each using the corresponding type table entry they need to compile either the tests or the new elements added. Then a declarative composite recipe pulls everything together to make it work across major versions upgrades. We do this a lot, for instance in our rewrite-spring module across 4 major versions of Spring.

[mensinda]

OK, thanks. I guess I should just try it out and see what happens instead of overthinking it too much. I will close / resolve this discussion once I have a working changeset for my other use-case.