Page 2 of 5 FirstFirst 1234 ... LastLast
Results 21 to 40 of 82
Like Tree9Likes

Thread: Generics & 'Type Erasure': disingenuous documentation?

  1. #21
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    No it shouldn't.
    Casting an array of something to an Object[] is not something that needs checking since everything is rooted in the Object class.

    It's possibly a side effect of the nature of arrays, but doesn't strike me as all that unusual.

    It all, essentially, boils down to..."don't write bollocks code".
    :)

  2. #22
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    No it shouldn't.
    Casting an array of something to an Object[] is not something that needs checking since everything is rooted in the Object class.

    It's possibly a side effect of the nature of arrays, but doesn't strike me as all that unusual.

    It all, essentially, boils down to..."don't write bollocks code".
    :)
    Well that is your opinion and I think it sidesteps the issue. The documentation says that it can lead to heap pollution and you are saying it doesn't need checking.

    And as for what you think it boils down to, that is a cop out.

    I wouldn't be surprised if what you are today defending, gets fixed. Then you'll be telling everyone how logical the new way is! :-)

    I expect to see generic type information in the runtime in some future release. I don't really believe it is all that difficult. They just haven't got round to doing it. They can stamp an array with its type, so why not a List. They don't have to use the stamp to break backward compatibility, just to trap heap pollution at the point where it happens.

  3. #23
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    But that would not fix the issue of casting SomeClass[] to an Object[], which has nothing at all to do with type erasure.
    Which is the point I was replying to.

    The above that you complained about being valid, is just as valid without touching Collections at all...

  4. #24
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    But that would not fix the issue of casting SomeClass[] to an Object[], which has nothing at all to do with type erasure.
    Which is the point I was replying to.
    Yes it would. The documentation states that the assignment introduces possible heap pollution. If you classes are stamped with their type at runtime, their wouldn't be any heap pollution. It would throw a runtime exception.

  5. #25
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Which has nothing to do with type erasure, since that is something specific to generics, and:
    Java Code:
    Object[] objects = new SomeClass[]();
    predates them by several years.

    You are conflating two different things here.
    Type erasure and everything extending Object.
    The former may well get "fixed" (though I wouldn't hold my breath since you'll get a runtime exception as soon as you try and use an array that's been buggered up), the latter is not likely to.

  6. #26
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    Which has nothing to do with type erasure, since that is something specific to generics, and:
    Java Code:
    Object[] objects = new SomeClass[]();
    predates them by several years.
    Huh? Heap corruption has nothing to do with type erasure??? ***scratches head***

    Quote Originally Posted by Tolls View Post
    You are conflating two different things here.
    Type erasure and everything extending Object.
    The former may well get "fixed" (though I wouldn't hold my breath since you'll get a runtime exception as soon as you try and use an array that's been buggered up), the latter is not likely to.
    I am not conflating the issues. I am looking at them as a whole. You are looking at the assignment in isolation. Of course you can assign any reference type to object, and any array reference type to object array.

    Put it this way, suppose I had a complex method which generated a warning about the conversion of its parameterized arguments. I didn't write the function, but I need to check where there may be possible misuse. The varargs themselves are not essentially the issue. That is just an artifact of how the Java compiler has been made to behave. The issue is at the assignment to object. That is where the vulnerability is exposed and where the compiler should flag. As it is, I could be left with some rather complex compilation analysis or be forced to relinquish the parametrization which may have been used in a totally proper way.
    Last edited by 2by4; 12-15-2011 at 07:04 PM.

  7. #27
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    We're obviously talking at cross-purposes.

    The array assignment marked as Valid in the code snippet from the docs has always been valid, and is valid for things that do not involve generics. Therefore that assignment (which is the only thing I have been talking about here) is nothing to do with type erasure. It is simply down to the nature of extending from a base object (and the associated logic behind arrays).

    So, as I said, it's a part of the language and is most unlikely to be changed.

  8. #28
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    I know it has been there since day 1. Object is at the top of the reference type hierarchy and can be assigned any reference type.

    But, when you evolve a language, there is impact. You can't just say that what was valid in earlier versions remains totally valid. You are tweaking the semantic perspective on the language and there is regression. So, I find the argument that it is valid because it was valid before, to be wrong.

    If you try to answer the question in my last post, you will see that the assignment to object ought now to be flagged, however valid it used to be before generics hit.

    (Reminds me of the same thing in the world of science. You can't build a world perspective in way that is entirely incremental and without review. Perspectives break, just like Newtonian Dynamics)

  9. #29
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Why should the cast to Object[] be flagged though?
    Will you flag casts to List<SomeClass>[] as well?
    How about any cast?
    Because that is essentially what you are suggesting...casting is always suspicious.
    Which, to be frank, is nonsense.

    Almost any artifact of a language is open to misuse.

    I'm curious, in your work have you encountered a problem with this aspect of Java?
    Because in over a decade working in it I honestly can't think of any in the stuff I've written or reviewed.

    Same goes for type erasure as well, as a matter of fact.
    Now, automatic primitive wrapping...that keeps causing trouble.
    Fubarable likes this.

  10. #30
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    Why should the cast to Object[] be flagged though?
    Will you flag casts to List<SomeClass>[] as well?
    How about any cast?
    Because that is essentially what you are suggesting...casting is always suspicious.
    Which, to be frank, is nonsense.

    Almost any artifact of a language is open to misuse.

    I'm curious, in your work have you encountered a problem with this aspect of Java?
    Because in over a decade working in it I honestly can't think of any in the stuff I've written or reviewed.

    Same goes for type erasure as well, as a matter of fact.
    Now, automatic primitive wrapping...that keeps causing trouble.
    No. The "nonsense" suggestion is entirely your own. Nowhere have I suggested flag all casts. If a cast fails at runtime, you know exactly where to look in the source code because it will tell you.

    You are still avoiding addressing the scenario in my last but one post, which is why you think any old cast is equivalent.

    The problem here is impact analysis. Earlier versions of Java didn't even flag the function declaration in the varargs problem. They only flagged the invocation. Now they've move the compiler error closer to the source of the error. But, as I said, please address the scenario, so that you comment more accurately on my perspective.

  11. #31
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Show us an example then...as code.

    I presume you have encountered something that does cause a problem in real life, and not merely as a mental exercise, that you could use here to illustrate your concerns.

    Then explain how you would restructure the byte code and JVM to handle this case (note, the array problem not the generics one) that does not cause backward compatibility problems. And maybe then you might see that this is rather unlikely to be tackled anytime soon.

  12. #32
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    Show us an example then...as code.

    I presume you have encountered something that does cause a problem in real life, and not merely as a mental exercise, that you could use here to illustrate your concerns.

    Then explain how you would restructure the byte code and JVM to handle this case (note, the array problem not the generics one) that does not cause backward compatibility problems. And maybe then you might see that this is rather unlikely to be tackled anytime soon.
    I think you are still looking at things in isolation and trying to separate one issue from the other, when they are joined at the hip.

    We have already seen a SIMPLE example of the problem from the Java Trail...

    Java Code:
      public static void faultyMethod(List<String>... l) {
        // Valid
        Object[] objectArray = l; 
        objectArray[0] = Arrays.asList(new Integer(42));
        // ClassCastException thrown here
        String s = l[0].get(0);
      }
    If this happened in real life, I would need to get at the line labeled "valid", because that assignment is the most specific one that relates to the incompatibility, and is amenable to the compiler. From there I can check what objectArray is doing that is violating l or any of its potentially many aliases.

    In a far more complex scenario, there may be many such candidates aliasing l in complex ways. The compiler should flag them.

    If I get a runtime exception, because the exception doesn't happen at the point of heap pollution, all I get to know is that something corrupted l. And the compiler only flags whole methods and says, "it's in one of these, chief".

    So I would have to examine the whole of the code: the method referenced by the runtime exception and methods in its call graph that were flagged, instead of specific variables. The "don't code crap argument doesn't really stand". In practice, you are often faced with debugging complex code you did not write yourself.

  13. #33
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    But as I said, that example is bollocks code.
    If I saw that in some real code I would take it out back and have it shot.

    How should the compiler know that the above is not a valid cast?
    And what changes are required in the runtime to make a runtime exception occur at the point of assignment? Presumably every "array[i] = something" will have to have a check the "something" is allowed in the underlying object?

    This is still a mental exercise. Do you have a concrete example?

    If you don't then maybe you might realise why this is not likely to be dealt with.

  14. #34
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    But as I said, that example is bollocks code.
    If I saw that in some real code I would take it out back and have it shot.
    Right.

    And "bollocks" code happens. And taking it out and having it shot costs $$$$$$$

    And the other point is "when do you get to see it" (presumably at runtime with an exception) and after you have trekked through a ton of code as I explained in my last post. $$$$$$$$$$$$$

    How should the compiler know that the above is not a valid cast?
    In the same way as it knows and flags List myList = List<String> myListString;

    And what changes are required in the runtime to make a runtime exception occur at the point of assignment? Presumably every "array[i] = something" will have to have a check the "something" is allowed in the underlying object?
    This is already the case.

    A string array cast from an object array does a runtime check precisely as you have described.

    They just haven't extended that runtime checking to generics.

    This is still a mental exercise. Do you have a concrete example?

    If you don't then maybe you might realise why this is not likely to be dealt with.
    I obviously am not going to post live code on the internet. What will complexity add to the point. What I think you want is a realistic scenario?

    Consider someone writing a method that manages numbers on a GUI. They create a List<String> because that is the most appropriate format. Someone else reads the spec and tries to use the List<String> as a List<Integer>, and are able to do so because legacy code is involved. They try to pull out an Integer in a location far removed from the for where the List<String> is declared. Presto! We have a very realistic scenario.

  15. #35
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by 2by4 View Post
    Right.

    And "bollocks" code happens. And taking it out and having it shot costs $$$$$$$

    And the other point is "when do you get to see it" (presumably at runtime with an exception) and after you have trekked through a ton of code as I explained in my last post. $$$$$$$$$$$$$
    Any company that doesn't do code reviews does not deserve to stay in business.
    Any company that does code reviews and allows the above through does not deserve to either.

    Quote Originally Posted by 2by4 View Post
    In the same way as it knows and flags List myList = List<String> myListString;
    No it doesn't.
    It flags the "List myList" part as being a raw type...nothing to do with the assignment.
    You really ought to check this...

    Quote Originally Posted by 2by4 View Post
    This is already the case.

    A string array cast from an object array does a runtime check precisely as you have described.

    They just haven't extended that runtime checking to generics.
    That's going from super to (possible) sub. Not the same as going from sub to super.
    Which is using the current mechanism, whereby the developer has to state the cast they are doing.
    Java Code:
    Object[] o = new Object[1];
    String[] s = (String[]) o;
    Which works with all casts, so you are suggesting changing how casting works (which takes me back to my point earlier about where do you stop).

    Quote Originally Posted by 2by4 View Post
    I obviously am not going to post live code on the internet. What will complexity add to the point. What I think you want is a realistic scenario?

    Consider someone writing a method that manages numbers on a GUI. They create a List<String> because that is the most appropriate format. Someone else reads the spec and tries to use the List<String> as a List<Integer>, and are able to do so because legacy code is involved. They try to pull out an Integer in a location far removed from the for where the List<String> is declared. Presto! We have a very realistic scenario.
    If they have a List<String> which is returned by their method, then the compiler will flag the attempt to use it as a List<Integer>.
    Or are you saying List, as a raw type. In which case there's nothing you can do about it. There's no way you can tell the compiler or runtime what the original coder intended as they used the raw type.

    So not a good example.

  16. #36
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    Presumably every "array[i] = something" will have to have a check the "something" is allowed in the underlying object?
    Need to throw a correction in here, because that bit there is wrong. As you say, it does a check on assignment. I forgot about the ArrayStoreException.

    But the idea of flagging upcasts (or whatever the term is) still makes no sense.

  17. #37
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    Any company that doesn't do code reviews does not deserve to stay in business.
    Any company that does code reviews and allows the above through does not deserve to either.
    I disagree. Expecting everyone to know that a list has never anywhere in the code base been aliased to List<String> is impractical.

    A code review won't pick it up except for the small apps.

    My scenario is almost bound to happen.

    No it doesn't.
    It flags the "List myList" part as being a raw type...nothing to do with the assignment.
    You really ought to check this...
    I am not talking about what it flags, but how it knows when to flag. Has it got the information to know that a raw type is potentially being allowed to be aliased to a generic type? Answer, yes, for the reason I have given.

    That's going from super to (possible) sub. Not the same as going from sub to super.
    Which is using the current mechanism, whereby the developer has to state the cast they are doing.
    Java Code:
    Object[] o = new Object[1];
    String[] s = (String[]) o;
    Which works with all casts, so you are suggesting changing how casting works (which takes me back to my point earlier about where do you stop).[/b]
    Well, yes, there are two points. Is the mechanism there? Yes it is.

    Will it proliferate? Well, you seem to be ambivalent about this. Firstly, you are saying it won't happen very often and code reviews are enough. Then you are suggesting that there will be proliferation. How many times do you have arrays of parametrized types. I don't think it would cause proliferation.

    If they have a List<String> which is returned by their method, then the compiler will flag the attempt to use it as a List<Integer>.
    Or are you saying List, as a raw type. In which case there's nothing you can do about it. There's no way you can tell the compiler or runtime what the original coder intended as they used the raw type.

    So not a good example.
    You miss the point. It is what the original coder intended for the List<String> type, not the raw type. The runtime can contain that information, and where the compiler has determined there is aliasing with raw type, putting a runtime check in to make sure String (and not Integer types) go into List<String>. That will require dynamically stamping List<String> as String type.

  18. #38
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Again, if no one is encoutnering this in real life (outside academic arguments) then they will not fix it.

    And, as I said earlier, I have never encountered this problem.

    As for the example, show me the code you suggest will cause the problem in your magical List<String> to List<Integer> discussion.

  19. #39
    2by4 is offline Banned
    Join Date
    Dec 2011
    Posts
    143
    Rep Power
    0

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    Quote Originally Posted by Tolls View Post
    Again, if no one is encoutnering this in real life (outside academic arguments) then they will not fix it.

    And, as I said earlier, I have never encountered this problem.
    I think they are closing in on the issue, but just not being upfront about it.

    Quote Originally Posted by Tolls View Post
    As for the example, show me the code you suggest will cause the problem in your magical List<String> to List<Integer> discussion.
    Well, I can't post "realistic" reams of live code, can I. I can only give an outline as in my earlier post.

    Let us say that an account number is an integer < 1000000 and is always displayed padded with leading zeros where necessary to make it 6 digits long.

    Method processReportData(), written before generics, takes reportType:String as a parameter and reportData:Object[] as another. reportData holds account numbers and other data, and its structure depends on account type. Related data for each account has to be read, analysed, cross-references and sorted. The method is complex and calls many other methods, but it so happens that passing in account numbers as Integers works fine because only the toString() and compare() methods of account number get called.

    This is exactly what is happening. A program that processes account data from an Excel spreadsheet sends it off for report preparation. The tranche of account numbers is identified by number ranges, and the programmer first converts the String representation of the account number to int, then creates a List<Integer> and calls the processReportData() method, described in the previous paragraph, for report type Excel. He knows that this report type expects a List as first element of the array.

    Everything works as expected and all the output looks fine.

    A year later, an enhancement requirement comes through stating that occasionally certain suspense accounts should be appended to the report. The appropriate place for this is the processReportData() method. The developer in this case treats account number as a String. He places this in reportData. Biko! We have heap corruption.

    A program higher up the call chain later pulls out this "IntegerString" and falls over!

  20. #40
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,172
    Rep Power
    20

    Default Re: Generics & 'Type Erasure': disingenuous documentation?

    And?
    Is that an actual occurrence you have encountered?

    As I said, I have worked in Java for over a decade and this is not something I have ever encountered post-1.5. No one is keeping anything hidden here...it is simply not happening the way you seem to think it is.

    Even pre-1.5 the interfaces were well documented (by necessity, sadly), and any use of an Object[] like that would have been questioned in any case.

    You talked earlier about the cost of this, but I suspect you don't realise what the cost of a reworking of (quite possibly) the JRE itself, or the dismantling of the Collections framework to accommodate this change, would entail. Regression testing for a simple JRE upgrade is fairly expensive as it is, but doing it for something that will likely break legacy code will simply result in companies not bothering to stump up the dosh.

Page 2 of 5 FirstFirst 1234 ... LastLast

Similar Threads

  1. Type Erasure
    By Lil_Aziz1 in forum New To Java
    Replies: 3
    Last Post: 06-29-2010, 09:57 AM
  2. min / max and documentation
    By jon80 in forum New To Java
    Replies: 1
    Last Post: 04-20-2008, 01:37 PM
  3. documentation
    By mcal in forum New To Java
    Replies: 4
    Last Post: 02-07-2008, 07:20 AM
  4. Java Documentation
    By ravian in forum New To Java
    Replies: 4
    Last Post: 12-04-2007, 10:45 AM
  5. ArrayList<type> - Generics
    By Java Tip in forum Java Tip
    Replies: 0
    Last Post: 11-14-2007, 04:21 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •