jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
Signup
groovy
  • groovy
  • GROOVY-3903

Generics ignored

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: 1.6.3
  • Component/s: None
  • Labels:
    None
  • Environment:
    windows xp
  • Number of attachments :
    0

Description

After a declaration of a collection with generics, the wrong types are inserted and accepted, even if the generics are also explicitly declared in the constructor. Code to reproduce it:

Map<String, Integer> map = [:]
map["foo"] = "bar"
println "map = $map"

Map<String, Integer> map2 = new HashMap<String, Integer>()
map2.put("foo", "bar")
println "map2 = $map2"

Output:
map = [foo:bar]
map2 = [foo:bar]

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
blackdrag blackdrag added a comment - 25/Nov/09 7:50 AM

Generics in Groovy are mostly a feature for compatibility with Java. You can use them yes, but only what is left after type erasure is really checked. In your case that is nothing.

Show
blackdrag blackdrag added a comment - 25/Nov/09 7:50 AM Generics in Groovy are mostly a feature for compatibility with Java. You can use them yes, but only what is left after type erasure is really checked. In your case that is nothing.
Hide
Permalink
peninha added a comment - 25/Nov/09 10:26 AM

That's a pity. Is there any chance that generics will be properly supported (ie. as in Java) in the future?

Show
peninha added a comment - 25/Nov/09 10:26 AM That's a pity. Is there any chance that generics will be properly supported (ie. as in Java) in the future?
Hide
Permalink
Russel Winder added a comment - 25/Nov/09 10:43 AM

Jochen, I wonder if there is an argument for printing a warning whenever Groovy sees generics, pointing people to a page on the wiki explaining why generics are a fundamental waste of time in any dynamic language that works directly on the JVM?

peninha, The JVM does not store type parameter information for objects instantiated from generic types – the wonders of "type erasure" mean that type parameters are compile time only and dynamic languages such as Groovy do not have access to that information when type checking is undertaken at run time. If you have to have run time type parameter checking then this will require a lot of extra infrastructure on top of the JVM or you have to switch to using CLR. So the upshot is that Groovy will likely never support type parameters unless or until they get included in the JVM.

Show
Russel Winder added a comment - 25/Nov/09 10:43 AM Jochen, I wonder if there is an argument for printing a warning whenever Groovy sees generics, pointing people to a page on the wiki explaining why generics are a fundamental waste of time in any dynamic language that works directly on the JVM? peninha, The JVM does not store type parameter information for objects instantiated from generic types – the wonders of "type erasure" mean that type parameters are compile time only and dynamic languages such as Groovy do not have access to that information when type checking is undertaken at run time. If you have to have run time type parameter checking then this will require a lot of extra infrastructure on top of the JVM or you have to switch to using CLR. So the upshot is that Groovy will likely never support type parameters unless or until they get included in the JVM.
Hide
Permalink
blackdrag blackdrag added a comment - 25/Nov/09 10:45 AM

well imagine

Map<String, Integer> map = x.y()

Java can check this, as it will know the type of x and the return type of the y method. If that information is not available the program won't compile. In Groovy we may not have that information for several reasons. That means we eiter cannot do the check and just accept it (like now) or we fail. Failing at runtime is a problem because the would need to check the generics types on method invocation, wrap the result of the method or other stupid things, which are very bad for performance. Failing at compile time forces a static nature Groovy just does not have.

So we could check some, like your example. But I am not for half hearted things.

Show
blackdrag blackdrag added a comment - 25/Nov/09 10:45 AM well imagine Map<String, Integer> map = x.y() Java can check this, as it will know the type of x and the return type of the y method. If that information is not available the program won't compile. In Groovy we may not have that information for several reasons. That means we eiter cannot do the check and just accept it (like now) or we fail. Failing at runtime is a problem because the would need to check the generics types on method invocation, wrap the result of the method or other stupid things, which are very bad for performance. Failing at compile time forces a static nature Groovy just does not have. So we could check some, like your example. But I am not for half hearted things.
Hide
Permalink
blackdrag blackdrag added a comment - 25/Nov/09 10:52 AM

Russel, that's the old question of if warnings are making sense or not. I am not so much for warnings. Also were to go with compile time warnings when running a script at runtime from source?

A wiki page might still be a good idea though

Show
blackdrag blackdrag added a comment - 25/Nov/09 10:52 AM Russel, that's the old question of if warnings are making sense or not. I am not so much for warnings. Also were to go with compile time warnings when running a script at runtime from source? A wiki page might still be a good idea though

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    peninha
Vote (0)
Watch (1)

Dates

  • Created:
    25/Nov/09 7:11 AM
    Updated:
    25/Nov/09 10:52 AM
    Resolved:
    25/Nov/09 7:50 AM
  • Atlassian JIRA (v5.2.7#850-sha1:b2af0c8)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.