Closed timtebeek closed 1 year ago
There could be a few more small corner cases. The Guava Javadoc actually tell you what the difference is and what the Java equivalent is. Also note that version 21 added the utilities fromJavaUtil()
and toJavaUtil()
which should be easy to replace :-)
That Comparison to java.util.Optional
note is helpful indeed; hadn't noticed that yet; think I arrived at mostly the same, but good to check that when implementing.
I think we can cover most of these quite nicely with declarative recipes already; the remaining ones might be doable with rewrite templates once that's further along, and don't seem to be as highly used as some of the other ones.
I thought a bit about this recipe and it seems like it could be a bit difficult to implement if we have to ensure that the type attribution is still correct everywhere. But I may think about it the wrong way.
Looking at some of the other recipes we seem to mostly call out to ChangeType
in similar cases.
This one would be slightly different as it would also require a first few ChangeMethodName
calls before ChangeType
, and dedicated recipes for the not-one-to-one cases. To start with I don't there's much else right?
I guess you are right. It probably just gets a bit weird when we rewrite uses of Guava Optional
where some called third-party API expects a Guava Optional
. Especially if this is just some other Guava API. But I guess this kind of problem can happen everywhere and is hard to do anything about. Of course, in this specific case, we could use the fromJavaUtil()
and toJavaUtil()
utilities in these places. But this sounds non-trivial.
The other problem I was thinking of is what happens to the type attribution between the ChangeMethodName
, ChangeMethodTargetToStatic
, and ChangeType
recipes and where in this order we insert the imperative recipes. Will the imperative recipe be able to rely on the type attribution to do its work?
Cases like Optional.fromNullable(null).or(Optional.of("foo"))
may require a very careful ordering of the recipes so that this works properly.
Mostly implemented in https://github.com/openrewrite/rewrite-migrate-java/pull/202 ; propose we close this one and pick up the asSet
and presentInstances
methods only when asked. Preferably by then we're further along with rewrite-templating to make that even easier to do.
We already have quite some recipes to convert Guava classes to standard JDK equivalents: https://github.com/openrewrite/rewrite-migrate-java/blob/main/src/main/resources/META-INF/rewrite/no-guava.yml Seems like Guava's Optional could be a nice addition to the list of supported migrations.
Guava
https://guava.dev/releases/19.0/api/docs/com/google/common/base/Optional.html
JDK
https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html
Quick analysis
There's a few cases that will need to be looked at in detail, such as: