import static org.assertj.core.api.Assertions.* clashes with URI (java.net.URI)

[mp911de]

Summary

Statically importing AssertJ assertions imports fields from InstanceOfAssertFactories. The URI field shadows java.net.URI and requires fully qualified naming when using java.net.URI.

There's a similar issue for URL as these two types match exactly constant names from InstanceOfAssertFactories.

Example

import static org.assertj.core.api.Assertions.*;

URI.create("http://foo")

Compilation failure:

PagedResourcesAssemblerUnitTests.java:[272,79] cannot find symbol
   symbol:   method create(java.lang.String)
   location: variable URI of type org.assertj.core.api.InstanceOfAssertFactory<java.net.URI,org.assertj.core.api.AbstractUriAssert<?>>

[joel-costigliola]

Thanks for reporting this @mp911de.

Thinking out loud, we might simply rename the factories to disambiguate this.

[mp911de]

That would help. URI and URL are the only two types where factory constants are clashing. All other types use some sort of different letter casing.

[filiphr]

Maybe this should have been part of the 3.13.1 release as well @joel-costigliola, as it seems to break existing code and the field names would need to be changed and removed.

[mp911de]

I have a similar impression. Getting this clash out of the way before wide adoption of 3.13.x would be helpful. Once a significant number of projects updates to 3.13 and relies on InstanceOfAssertFactories.URL/URI, the rename will break their code.

[scordio]

Thanks for reporting this @mp911de.

Thinking out loud, we might simply rename the factories to disambiguate this.

@joel-costigliola That would be an option, e.g., having URI_INSTANCE URI_TYPE instead of URI.

Or another option would be to have Assertions not implementing InstanceOfAssertFactories. That was introduced to simplify the discovery of the factories, but we realized that for Eclipse was not enough anyway and IntelliJ seems still able to discover them using the smart completion.

[joel-costigliola]

Renaming URI to URI_TYPE and URL to URL_TYPE seems the best option. @scordio do you want to tackle this one ?

We will release 3.13.2 at the end of the week just to get a bit more feedback.

[scordio]

@joel-costigliola yes I'll take care of it.