Incorrect transformation of annotation value. about transformer

[bjhargrave]

I don't think this is an issue we need to worry about.

The string constant is a default value for an annotation element. For example:

https://docs.jboss.org/hibernate/beanvalidation/spec/2.0/api/javax/validation/constraints/AssertFalse.html#message--

This is addressed in the Jakarta Validation API:

https://github.com/eclipse-ee4j/beanvalidation-api/blob/fca91fff18c19c4101ac3b0166b5a86c8626b355/src/main/java/jakarta/validation/constraints/AssertFalse.java#L41

Such default values don't appear in classes using the annotation. Just in the annotation class itself.

While one can use Transformer to try and convert the Jakarta API from "javax" to "jakarta", the is more properly done in the source code for the Jakarta API as above.

So in this case, I don't think there is an issue we need to address.

[dblevins]

User code can define annotations with defaults. In the case of Bean Validation, the API only works by users defining their own annotations that other developers can use. Those user defined bean validation annotations can legally reference any class.

CDI is an API that also encourages users to create annotations to represent qualifiers, stereotypes, scopes, etc. We can't really guarantee that those annotations don't have defaults that may reference javax classes or have strings that need to be replaced. If users of the annotation didn't explicitly set the value and relied on the default, in that scenario all their code would break.

[bjhargrave]

I understand that String defaults in annotation defining classes may need transformation. That should fall under the general heading of String constant transformation rather then something special for annotation defaults.

I was referring to the example cited above which is itself already handled by Jakarta source code changes.

[dblevins]

Sorry, didn't mean to close. Was reading #43 attempting to get a better understanding as they seem like the same issue.

[dblevins]

For my benefit as I don't really know the code yet, from a purely user perspective are we saying that if a user references a javax class in a string in a method block or field, we will update that string automatically if the class referenced by the string was renamed. But if the string that references the renamed class is in an annotation or annotation default, they need to handle that themselves and configure it in their string transformations?

Not a challenge, just trying to understand.

[dblevins]

And amen to your comment on #43 "This is unfortunately very hard since strings can be anything while class names can only be class names."

I'm still not clear on what our capabilities are with updating strings; if it is all mapped by the user or if there are some things done automatically and where the line is.

[bjhargrave]

The code processes the Constant Pool which hold String constants. It looks for String constant values that are binary type (/ separated), descriptors ((Lclass;)V) and also direct string replacement (for such configured rules).

transformer/org.eclipse.transformer/src/main/java/org/eclipse/transformer/action/impl/ClassActionImpl.java

Lines 1268 to 1292 in dc50865

	case ConstantPool.CONSTANT_String : {
	StringInfo stringInfo = constants.entry(constantNo);
	String inputString = constants.utf8(stringInfo.string_index);
	transformCase = "constant"; // dotted package format
	String outputString = transformConstantAsDescriptor(inputString,
	SignatureRule.ALLOW_SIMPLE_SUBSTITUTION);
	if (outputString == null) {
	transformCase = "String"; // url format (slashes)
	outputString = transformConstantAsBinaryType(inputString,
	SignatureRule.ALLOW_SIMPLE_SUBSTITUTION);
	if (outputString == null) {
	transformCase = "Direct";
	outputString = transformDirectString(inputString);
	}
	}
	if (outputString != null) {
	constants.entry(constantNo, new StringInfo(constants.utf8Info(outputString)));
	modifiedConstants++;
	debug(" String: {} -> {}", inputString, outputString);
	verbose("String: {} -> {}", inputString, outputString);
	} else {
	debug("Skip string {} (unchanged)", inputString);
	}
	break;
	}

But this does not cover . separated types (which are not used by the JVM) but are commonly written by users. The String constant in the initial comment here is not even a type name. It is a string which contains something resembling a . separated type name. So absent a direct string rule, it would be unprocessed.

#44 suggests that we probably need more fine grained control over the rules for direct string replacement. This is probably true. We may also want to support more complex string replacements rules including regex to handle certain cases.

[dblevins]

That's super clear. Thanks so much. More complex string replacements would be awesome. If I can think of any clever design ideas, I'll raise another issue.

Appreciate the patience :)

[tbitonti]

Hi, is this still an issue?

[jgallimore]

Thanks for the nudge. I suspect its ok, but I'll check on our side and update.

[bjhargrave]

Closing since no feedback that the issue still exists.