0

While generating java code from Avro scheme using commerce hub Gradle plugin, it takes the object which has a field such as

"name": "ruleKey",
"type": [
  "null",
  {
    "type": "enum",
    "name": “Rule”,
    "namespace": "com.testing.common.rules.api",
    "symbols": [
      "MIN_AGE",
      “MAX_AGE”
    ]
  }
]

, and generates Java class from the scheme, including enum fields such as Rule. In the same time, I am importing common rules(com.testing.common.rules.api) and it imports Rule as well. I would like to use methods from the common library, however, Avro generated model has a higher priority. ( The Java interpreter will look for classes in the directories in the order they appear in the classpath variable. In this case, the ones generated from the scheme) and it doesn’t let me use the imported class from the common library, because Avro already generated Rule enum class with the same package and name.
The used technologies are spring boot 2, Java 10 and commercehub.gradle plugin.

Etibar - a tea bar
  • 1,912
  • 3
  • 17
  • 30

2 Answers2

0

IDEA honors class path ordering. First match wins ( as you already found out ) - so you have to reorder classpath elements in your project / module classpath setting.

Konstantin Pribluda
  • 12,329
  • 1
  • 30
  • 35
0

Actually, none of the things you listed in your question really matter. As in: you have two classes x.y.Z, with the same name, and the package.

And that doesn't work. When you import x.y.Z, the JVM starts searching the class path, and will pick the first class it find. And there is nothing you can do about that.

Thus, the only solution: make sure that your class path only contains the class you intend to use. This is also a good preparation for the future, as Java9 will not allow you to have two modules with conflicting x.y.Z classes (in the same layer).

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Actually, I didn't say out one part, in my case field Rule comes from a common library . Rule is a field in the scheme and in the same time it is imported by the project. When we generate java code from the scheme, then JVM understands it as two classes with the same name, and the package. However, it is basically the same, one generated from Avro scheme, another one imported from the common library. If there was a way to 'tell' avro plugin not generate the field, use existing ones, it would solve the issue. – Etibar - a tea bar Nov 20 '18 at 10:30