Skip to content

Conversation

@Njeriiii
Copy link
Owner

@Njeriiii Njeriiii commented Jul 29, 2024

What does this implement/fix? Explain your changes.

This class is an inspection tool that checks if a variable type is an Azure implementation type.
If the variable type is an Azure implementation type, or if the variable type extends or implements an Azure implementation type, the inspection tool will flag it as a problem.

Has this been tested?

  • Tested

Any relevant logs, screenshots, error output, etc.?

image

return false;
}
// Check if the class is in the Azure package and if it is an implementation type
return psiClass.getQualifiedName().startsWith(RuleConfig.AZURE_PACKAGE_NAME) && psiClass.getQualifiedName().contains(RULE_CONFIG.getListedItemsToCheck().get(0));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not use get(0) as this will only check the first element in the list of configured rules.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's only one entry and its in String form.

We ended up with .get(0) for cases where there's only one String listedItemToCheck, but other rules have a list listedItemToCheck so instead of having a RULE_CONFIG attribute for String ItemToCheck and List listedItemToCheck we can just keep the list attribute, and when a String is encountered, it returns a list with one entry

"antiPatternMessage": "Endpoint should not be used with KeyCredential for non-Azure OpenAI clients"
},
"ImplementationTypeCheck": {
"typesToCheck": "implementation",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not really a "type". It's a sub-package name. So, we should consider changing the name here.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done - using subPackageName now

@Njeriiii Njeriiii requested a review from srnagar July 31, 2024 00:26
Comment on lines 127 to 132
if (interfaces.length == 0 && superClass != null && superClass.getQualifiedName().equals("java.lang.Object")) {
return false;
}

// Case 2: Class has implemented interfaces or extends a class that is an implementation type
if (interfaces.length > 0 || (superClass != null && !superClass.getQualifiedName().startsWith("java."))) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to check this? We should check if any of the parent classes are using Azure types and not check for super types that are in java.* package.

Copy link
Owner Author

@Njeriiii Njeriiii Aug 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was eliminating types in the java.* package so to check for everything else.
I've refactored the whole extendsOrImplementsImplementationType method to check for chains of superclasses & interfaces now

}

// If the super class is from the Azure package and is an implementation type return true
String superClassName = superClass.getQualifiedName();
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There can be a chain of superclasses. We should check for the whole chain.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've refactored the whole extendsOrImplementsImplementationType method to check for chains of superclasses & interfaces now


// If the super class is from the Azure package and is an implementation type return true
String superClassName = superClass.getQualifiedName();
return superClassName != null && superClassName.startsWith(RuleConfig.AZURE_PACKAGE_NAME) && superClassName.contains(RULE_CONFIG.getListedItemsToCheck().get(0));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should call the isImplementationType method instead of duplicating the logic.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've refactored the whole extendsOrImplementsImplementationType method to recursively check for chains of superclasses & interfaces now

@Njeriiii Njeriiii requested a review from srnagar August 1, 2024 18:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants