[Java] Model discovery issues in Entity class

[ramsessanchez]

Currently we are unable to publish java V1 and beta SDKs due to compilation errors relating to the namespace and sub-namespaces in which some of the models are generated into.
The Entity class, found in com/microsoft/graph/models/Entity.java references nearly every generated model in the function createFromDiscriminatorValue(). Upon compiling we were running into an issue as the package namespace of the Entity class was described as Microsoft.Graph.models where it should have been com.Mircosoft.Graph.models in order to accurately reflect the structure of our java project. This issue is addressed in this PR.
Upon addressing this issue a second issue became apparent. There are sub namespaces in the Models package, ex: com.microsoft.graph.models.security, which also store other generated models. These models are also referenced in the aforementioned Entity class. The issue here is that we are not able to discover these models without explicitly importing the sub namespaces in which these models are held, i.e.. 'import com.microsoft.graph.models.security.*'.
Furthermore, there is a class which is referenced in the Entity class, Identity.java, which has two definitions. The first definition is defined in com/microsoft/graph/models/Identity and the second in com/microsoft/graph/models/externalConnectors/Identity. The issue here is that naturally it will reference the first definition since it lives in the same namespace as the Entity class referring to it, however that class is not of the correct return type thus causing a return type error. These issues can be seen here.
The fixes that would lead to solving these issues can be seen here. I have taken the liberty to merge these changes into the feature/6.0 branch of the Java v1 and beta Sdk repositories although I am aware they will eventually be replaced by next weeks generation, however we have been tasked with releasing a preview of these Libraries thus the necessity to make these changes while we figure out a solution. I believe that we can either add these import statements or we can explicitly refer to every model by it's fully qualified name in order to prevent ambiguity and referencing issues at compile time. I believe the second would be a more complete solution, please let me know your thoughts. Thanks!

[MIchaelMainer]

We should certainly refer to every model by its fully qualified name. We will have name collisions at some point. This change is breaking for typewriter generated Java models, correct?

[baywet]

Thanks for bringing this up.

@andrueastman ran into similar issues with dotnet while releasing previews, but those issues could very well be limited to dotnet. This is why I didn't want to make a general rule of "every type reference must but fully qualified in every language". The reason why it could be a bigger problem in dotnet than in other languages is because dotnet using statements are comparable to star imports in other languages. (i.e. using Company.Foo.Bar; imports every symbol living under Bar, and the java equivalent would be import Company.Foo.Bar.*; which we aren't doing).

Regardless, this is internal implementation details we can always review once shipping (changing from imports to fully qualified references is not going to break anybody). And as mentioned on the chat, we have a setting that looks suspicious for Java discriminator values (should be true).

Changing everything to a fully qualified reference would be a "heavy" change, my suggestion is that we try to switch that setting and see whether it unblocks us for the time being. Thoughts?

If we're on the same page, @ramsessanchez please proceed with the investigation.

[andrueastman]

For the discriminator method specifically, you can take a look at the code below that decides to use the fully qualified name in the event duplicate/multiple key mappings exist in the discriminator mappings list so that fully qualified names are used.

kiota/src/Kiota.Builder/Writers/CSharp/CSharpConventionService.cs

Line 99 in f63adb6

// Get the discriminator mappings that refer to types are in a different namespace that are have the same name

[ramsessanchez]

As mentioned by @baywet switching the value from 'false' to 'true' seems to have added all the required import statements for all the required models. It does add quite a lengthy amount of import statements, however, this should unblock generation and previews going forward. I'll add this pr and link it here once created. I do think the quantity of import statements is quite large, but as stated earlier, removing import statements are replacing with fully qualified names shouldn't be a breaking change if implemented later on.

[baywet]

Thanks for confirming, closing

[ramsessanchez]

#1807