On Sunday 1 September 2019 19:34:59 CEST, Asmus Freytag wrote:

The challenge might be to define a signature to scan for for the first category to determine whether its a conduit for EAI. Are there API calls that would be indicative?

No. EAI is designed such that APIs tend to need no changes. This is on purpose. For example, a java app that supports email object may use a validation class called 'Email'. If the framework version is new enough to support EAI, then the app's Email objects perform a somewhat different validation than if not. The app itself doesn't really notice any difference (the Email class is framework-provided, it's not in the app).

No difference, that is, except that the developers likely haven't tested with EAI addresses. The second commandment of my religion is "that which hasn't been tested yet doesn't work yet". There always is some spoilsport detail.

So, you would scan such code projects for references to such an E-mail class and then see whether the code manipulates the inputs/outputs in a way that would break EAIs. Or, alternatively, whether the code just serves as neutral conduit.

That amounts to "testing by inspection" and I'm not sure it can be carried out in a useful way; it seems fundamentally not too different from checking whether code is utf-8 safe by looking at how it interacts with string classes.

A./