Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

Static import with same static variable names  RSS feed

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I am doing a static import of static members of class Long and Integer as shown below :


Now if i am trying to use this variable MAX_VALUE and print it , i will get an error as shown below :


This is fine. To remove the error i will have to remove one static import to resolve this ambiguity .

   The main issue i am getting is, if i use wildcard * with Integer class static import, the class gets compiled with no errors as shown below .



The ambiguity must still exist . Why does this compile with no issues ?

Note : If i use wildcard in Long static import instead of Integer, the code still compiles with no error . The output with wildcard with Integer static import is Long.MAX_VALUE and in other case it is Integer.MAX_VALUE.
 
Bartender
Posts: 4532
50
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because you have ...Integer.* it will still pull in all of the Integer constants, including Integer.MAX_VALUE.
 
Nishant Sinngh
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thats whats my reasoning was @Carey. And as per your statement, the code must not compile ,but it does . This is what i am asking actually. Why does it compile inspite of the ambiguity ?
 
Marshal
Posts: 59769
188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Nishant Sinngh wrote:. . . Why does it compile inspite of the ambiguity ?

Don't know.
I tried going through the Java® Language Specification and seeing whether it says anything about single static imports taking precedence over on‑demand static imports. Didn't find anything. Try this JLS section and see whether there is anything helpful there.
 
Saloon Keeper
Posts: 9138
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Specific imports always take precedence over wildcard imports. In the past, I've depended on this behavior in cases such as this:
 
Campbell Ritchie
Marshal
Posts: 59769
188
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Specific imports always take precedence over wildcard imports. . . .

Aaaaaaaaaaaaaaaaaah! Is there a JLS section telling us that? Is it the 2nd bullet under §6.5.2:-

JLS .5.2 wrote:• Otherwise, if a field of that name is declared in the compilation unit (§7.3) containing the Identifier by a single-static-import declaration (§7.5.3), or by a static-import-on-demand declaration (§7.5.4) then the AmbiguousName is reclassified as an ExpressionName.

Does it explicity say that single imports take rpecedence over on‑demand imports?
 
Stephan van Hulst
Saloon Keeper
Posts: 9138
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The Java® Language Specification Java SE 8 Edition wrote:
A single-type-import declaration d in a compilation unit c of package p that imports a type named n shadows, throughout c, the declarations of:

  • any top level type named n declared in another compilation unit of p
  • any type named n imported by a type-import-on-demand declaration in c
  • any type named n imported by a static-import-on-demand declaration in c

  • https://docs.oracle.com/javase/specs/jls/se8/html/jls-6.html#jls-6.4.1
     
    Campbell Ritchie
    Marshal
    Posts: 59769
    188
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Got it
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!