Classic Java language WTF



  • @CodeSimian said:

    Do you have a problem with what I wrote?
     

    Yes, but I don't think you understand why.

    Anyway, this thread was obviously started to provoke a flamewar, and since I have no emotional stake in Java or in people who think (for whatever reason) that pointers should be implemented in Java, I bow out.

     

    There was no WTF in the OP. The OP either doesn't understand the basic concepts at play, or meant to start a flamewar when some noob posted "OMGWTF Why??".



  • @dlikhten said:

    In any case, why does anyone care if java caches integer objects? I am just curious why we should care. Is it causing problems? Is 1 sometimes 3 but often 5?
    The perceived problem is the relational operators (=, !=, <, >, <=, and >=) act in arguably unexpected ways when autoboxing comes into the picture.  Before autoboxing, an object was an object and a primitive was a primitive.  Now, an object is sometimes a primitive, unless it would break backwards compatibility.

    Obviously not everybody on this thread agrees.  The fact that others out there on the internet have bothered to discuss this behaviour at least proves that if I am a complete moron for thinking this is even an infinitesimally tiny issue, at least I have company.



  • @MasterPlanSoftware said:

    @CodeSimian said:

    Do you have a problem with what I wrote?
     

    Yes, but I don't think you understand why.

    Anyway, this thread was obviously started to provoke a flamewar, and since I have no emotional stake in Java or in people who think (for whatever reason) that pointers should be implemented in Java, I bow out.

    I never said pointers should be implemented in Java.  I'm pretty sure I didn't imply that either.  I apologize if I did.

    Maybe you missed my point.  My point was that Java removed pointers, operator overloading, etc. for the sake of simplicity (allegedly).  IMO autoboxing makes the language slightly more complicated (unnecessarily), so it contradicts Sun's own design philosophy.

    I don't care if you attack that line of reasoning, but please don't attack me for something I never said or implied.  (And I will try to do the same).



  • @CodeSimian said:

    for something I never said or implied.
     

    @CodeSimian said:

    Strangely enough, Java doesn't implement pointers either.  I wonder why.



  • @MasterPlanSoftware said:

    @CodeSimian said:

    for something I never said or implied.
     

    @CodeSimian said:

    Strangely enough, Java doesn't implement pointers either.  I wonder why.

     

    You are reading the wrong implication into my statement "I wonder why".  I meant to imply that Java doesn't implement pointers BECAUSE OF SIMPLICITY, which ties into my argument that autoboxing is not simple, because it is implicit behaviour which can be potentially confusing.  I was attempting to be sarcastic.

    I apologize for my poor communications skills.  Seriously.



  • @CodeSimian said:

    my argument that autoboxing is not simple, because it is implicit behaviour which can be potentially confusing.
     

    I recommend BASIC.



  • @MasterPlanSoftware said:

    Filed under: Future SS quote

    Funny you should compare me to SpectateSwamp.  Actually a lot of the stupid stuff he says is taking out of context and actually makes sense if you try to figure out what he meant to write.  For example, people laughed at him when he said he was putting out bait for dino mummies.  Ha ha, people said, how can you put out bait for dead things?  It makes more sense when you realize he was writing metaphorically, and he meant that he was trying to bait paleontologists with his words, for dino mummies.

    So go ahead, flame away. 



  • @MasterPlanSoftware said:

    @CodeSimian said:

    my argument that autoboxing is not simple, because it is implicit behaviour which can be potentially confusing.
     

    I recommend BASIC.

    Like I said, flame away.  I have no problem with Java as a whole, I enjoyed using it in the past and I would gladly use it in the future, if I have the opportunity.  I'm sorry that I don't love everything about it.  It's possible to like something and still see the flaws.  There are plenty of flaws in C, C++, etc, yet I continue to use those languages.



  • @MasterPlanSoftware said:

    @CodeSimian said:

    my argument that autoboxing is not simple, because it is implicit behaviour which can be potentially confusing.
     

    I recommend BASIC.

    I don't mind complexity in and of itself.  I am claiming that Java is seemingly contradicting its own design goals (or marketing philosophy, or whatever) with the autoboxing feature.  I admit that many people might not agree on that point.  

    That's all.



  • @CodeSimian said:

    Like I said, flame away.  I have no problem with Java as a whole
     

    Wait, why are you consistently injecting an argument that he already declined to make, ie, "java is teh suxx0rz"? Nobody is arguing your take on Java as a whole except for you. I don't even think MPS was flaming you.

    Sense of humor, is that you? 

     



  • @sootzoo said:

    @CodeSimian said:

    Like I said, flame away.  I have no problem with Java as a whole
     

    Wait, why are you consistently injecting an argument that he already declined to make, ie, "java is teh suxx0rz"? Nobody is arguing your take on Java as a whole except for you. I don't even think MPS was flaming you.

    Sense of humor, is that you?

    Fair enough.  But I think his argument is people should not whine about "expected and documented" behaviour in Java. Perhaps, but I don't think said behaviour is intuitive or logical.

    Whatever, it's not important, and neither is my opinion on this stuff. 



  • @CodeSimian said:

    Whatever, it's not important, and neither is my opinion on this stuff. 
     

    I'd buy you a beer, but I think you have had enough.



  • @MasterPlanSoftware said:

    @CodeSimian said:

    Whatever, it's not important, and neither is my opinion on this stuff. 
     

    I'd buy you a beer, but I think you have had enough.

    Thanks!  (Believe me, the irony of writing "it's not important" after filling this thread with posts is not lost on me.)


  • @MasterPlanSoftware said:

    @Aaron said:

    Given that "int" is just an alias for the Int32 class in C#
     

    In C# there is an Integer class. 

    Int32 is an alias, Integer is a wrapper.

     <hints id="hah_hints"></hints>
    Strange that Intellisense doesn't recognize "Integer" and there's no mention of it in the MSDN.

    Are you sure you're not confusing the C# implementation with the Java implementation?  C# doesn't "wrap" primitives; it implements them as structs or classes that descend from ValueType, and autoboxes them when necessary (which is rarely the case these days).  The reserved words "int", "double", "decimal" etc. are just aliases for these structs.

    VB does have an "Integer" data type, but its corresponding CLR data type is still Int32. 

    The only real disadvantage to this approach was that in the 1.0/1.1 framework, the boxing added unnecessary overhead when using simple collections like ArrayList.  'Course, ever since Generics came out in 2.0, that hasn't been an issue either. 



  • @CodeSimian said:

    @dlikhten said:

    In any case, why does anyone care if java caches integer objects? I am just curious why we should care. Is it causing problems? Is 1 sometimes 3 but often 5?
    The perceived problem is the relational operators (=, !=, <, >, <=, and >=) act in arguably unexpected ways when autoboxing comes into the picture.  Before autoboxing, an object was an object and a primitive was a primitive.  Now, an object is sometimes a primitive, unless it would break backwards compatibility.

    Obviously not everybody on this thread agrees.  The fact that others out there on the internet have bothered to discuss this behaviour at least proves that if I am a complete moron for thinking this is even an infinitesimally tiny issue, at least I have company.

     

    In c you can access memory that has been deleted but not yet picked up by windows (was a SimCity bug in DOS which was added as a compatibility feature in Win95)... Why? I don't know its bad code style. You can shoot your nuts off with some wierdness features of Java... you can do object == comparisons in strange places where its not very obvious that it would evaluate to true.... Point is DONT AUTOBOX AND USE > < == != etc... Autobox is meant for doing


    List.add(10);

    instead of

    List.add(new Integer(10));


    and


    int x = List.get(0);

    vs

    int x = ((Integer) List.get(0)).intValue();


    You can see where the savings is... I never had a need to use the Integer object anymore, its just used by autoboxing to store objects into List or Map or w/e. Integer class is still useful for conversions.

    So stop poking at your sores and saying it hurts. Just don't do stupid shit.



  • @dlikhten said:

    You can see where the savings is... I never had a need to use the Integer object anymore, its just used by autoboxing to store objects into List or Map or w/e.
    Thanks, I understand the purpose of autoboxing.@dlikhten said:
    So stop poking at your sores and saying it hurts. Just don't do stupid shit.
    Since I obviously have no credibility left in this thread, I'll quote someone else (sorry, bstorer):

    @bstorer said:

    @MasterPlanSoftware said:
    Filed under: Behavior is expected and documented.
    Behavior is also stupid and counter-intuitive
    Again, it's not a question of whether or not I understand autoboxing.  It's just whether or not I like it, as implemented in Java.  Just for fun, you might want to see what others think of autoboxing in Java:

    http://www.google.ca/search?q=autoboxing+confusing

    Yes, you could argue they are all idiots.  Maybe they are and maybe I am, too.   Oh well.


  • Garbage Person

    The only way anyone would ever write this code is if they learned to program using VB and then immediately moved to Java without even bothering to read chapter 1 of a textbook

    Autoboxing and autounboxing are your fucking friends.



  • @Weng said:

    The only way anyone would ever write this code is if they learned to program using VB

    Or C++, or Ruby, or any other language that does it in a more consistent way.


    @Weng said:

    Autoboxing and autounboxing are your fucking friends.
    Except when they imply an abstraction they don't actually provide, which is the problem here.



  • @bstorer said:

    @Weng said:
    The only way anyone would ever write this code is if they learned to program using VB

    Or C++, or Ruby, or any other language that does it in a more consistent way.

    @Weng said:


    Autoboxing and autounboxing are your fucking friends.
    Except when they imply an abstraction they don't actually provide, which is the problem here.
     

    Correct.

    However my project is in java. I am paid to work in Java. I am also NOT paid by the character, so I take help where I can find it. Autoboxing saves me time in typing all that hokey crap and I don't use it in wierd ways. If I could program in Ruby at work I would, but I cant so I don't.

    I agree that Java is not completely consistent. Java was a good STEP in the right direction after C++ but Java is FAR from the best solution. I think Python and even better Ruby is a solution we should all be using, but Java has more momentum so for now we are stuck with it.



  • @belgariontheking said:

    <completely_wild_speculation>

    I guess Sun's seeing a backlash from other languages (Ruby) that developers are really starting to get into and which require a lot less code to do the same things as Java does, and they wanted to start reducing the amount of code Java developers have to write.  They chose the wrong way to do it, though

    </completely_wild_speculation>

    That may be, but I disagree that it's the wrong direction. Autoboxing makes sense and is useful and readable when passing in an int into a collection, for instance. Furthermore, comparing object references isn't something you should be doing unless you know what you're doing. In fact, the compiler should probably give a warning about it, I still get bitten by than one from time to time. Provided the warning can be disabled, that is, with e.g. some annotation.



  • @dlikhten said:

    Point is DONT AUTOBOX AND USE > < == != etc... Autobox is meant for doing...
    And my point is if autoboxing is not meant for comparisons, then it shouldn't have been implemented for relational operators.  Sun could've said: "Okay, we'll only implemented autoboxing for assignment operators and construction."  Even that would've more logical and consistent than the current situation.

    Again, Sun claims Java is supposed to be simple

    http://java.sun.com/docs/white/langenv/Simple.doc2.html

    Source code written in Java is simple

    ...

    Whether that claim matches reality is up for debate, I guess.



  • @dlikhten said:

    Autoboxing saves me time in typing all that hokey crap and I don't use it in wierd ways.

    You don't have to use it in weird ways to make the abstraction break down. I can use autounboxing for some comparison operators but not others. I understand the reasons why. But any way you slice it, that's just badly designed.


    @dlikhten said:
    Java was a good STEP in the right direction after C++

    You keep saying things like this, and they're idiotic. Java in not C++ 2.0 or something. They're different languages with different origins, different goals, and different flaws. They share much of the same syntax, but that was done to make Java seem familiar more than anything else. Do you think Javascript is some sort of new version of C++, too?



  • @bstorer said:

    You don't have to use it in weird ways to make the abstraction break down. I can use autounboxing for some comparison operators but not others. I understand the reasons why. But any way you slice it, that's just badly designed.
    Thanks for posting that, bstorer.  This is pretty much the argument I was trying to make.  Unfortunately, my crappy communication skills and poor debating abilities made me look like a wild-eyed idiot baying at the moon, whereas your argument sounds completely sane and reasonable.


  • Garbage Person

    @bstorer said:

    @Weng said:
    The only way anyone would ever write this code is if they learned to program using VB

    Or C++, or Ruby, or any other language that does it in a more consistent way.

    Actually, I wasn't even talking about autoboxing at all right there. I was talking about writing out "Integer" and expecting it to behave exactly as a fucking primitive. Anyone debugging this problem who knows a damned thing about Java would either go "WTF WHY DOES THAT EVEN TRY TO WORK!?" (pre-1.5 developer) or "Oh, autoboxing. Duh." (post-1.5 developer) and stab the person who originally wrote it.

    I'm not going to pretend that Java's comparison operators don't need to be overloaded for certain primitive-ish objects (String, and the wrappers), but they really can't without unpredictably breaking existing code. And at the same time, they'll have to roll out some pointer-comparison operator so we can still do crap like:

    if(someDataStrucute.next() == someSpecificObjectWeAreLookingFor) { doSomething() }

    By default, the comparison operators should use an object's compare() and equals() methods, since they're more common, but we still need some way to do pointer comparisons (at least for equivalency)

    I figure they'll do that right about the time they remove all those deprecated methods and classes they've been sitting on. Which will be... Never.



  • @bstorer said:

    Java in not C++ 2.0 or something.

    I think Bjarne Stroustrup would disagree with you there.  C++ is obviously designed as a predecessor to Java.  So perhaps instead of saying "Java is C++ 2.0" we should be saying "C++ is Java 0.5".



  •  The real wtf is that there has not been a strict, clear and simple difference between value and refernece comparison, like this:

        a == b    if the value of a is equal to the value of b
                      (like a.equals(b),  but simple and won't break when a===null)
        a === b  if and only if a and b refer to the same object
                      (and always [well, except in the case a===a] false for primitives, since they are
                      always stored in difference memory location, => strict)                

    Then you can compare objects and primitives exactly the same way.
    And as assignment logically follows:

       a = b      copy the value of b to a  => a == b but not a === b (except if it were this way before)
       a := b     make a equal to b => a == b and a === b

     



  • @Weng said:

    Actually, I wasn't even talking about autoboxing at all right there. I was talking about writing out "Integer" and expecting it to behave exactly as a fucking primitive.

    Which it does in many other languages, because they don't have this false barrier between primitives and classes. C++ had defensible reasons for doing this, Java really doesn't.


    @Weng said:
    I'm not going to pretend that Java's comparison operators don't need to be overloaded for certain primitive-ish objects (String, and the wrappers), but they really can't without unpredictably breaking existing code.

    Actually, String has its own inconsistencies, too. The fact that + is overloaded for String but not other objects is stupid.


    @Weng said:
    we still need some way to do pointer comparisons (at least for equivalency)

    I'm well aware of the problem. But Java's solution was (arguably) the wrong one to begin with, but when autoboxing rolled around, it highlighted the flaw.


    @Weng said:
    I figure they'll do that right about the time they remove all those deprecated methods and classes they've been sitting on. Which will be... Never.

    Most likely. There's crap in there that's been depreciated since I learned the fucking language 8 years ago.



  • @morbiuswilters said:

    @bstorer said:

    Java in not C++ 2.0 or something.

    I think Bjarne Stroustrup would disagree with you there.  C++ is obviously designed as a predecessor to Java.  So perhaps instead of saying "Java is C++ 2.0" we should be saying "C++ is Java 0.5".

    Wrong. The successor to C++ is C++0x, and it will suck all the joy from this world and devour our souls. The predecessor to Java is obviously Microsoft J++. It's so clear: C++ -> J++ -> Java. I don't know why Sun replaced the "++" with "ava".



  • Look if they wanted true autoboxing behavior that is consistent they would eliminate primitives. The java interperetor would know that certain operations can be done in primitive (fast) mode, and some can only be done in Object (slow) mode. Thats it. We should never have to think Integer or int ever again. I think that Integer is just an artifact of the past that autoboxing solves for you. With autoboxing you don't need to ever use Integer yourself unless you are parsing a string. Just always use int and let java box it into an Integer. Where is the problem?

    Just because you can do Integer x = 10 does not mean you should... what you should be doing is  int x = list.get(0) /* returns Integer(10) */ and then deal with the damn primitive.

     <assumption>

    Java can only go so far by keeping backwards-compatibility AND making the language better by simplifying it and making the VM smarter. Hell we still have Vectors.

    </assumption>



  • @bstorer said:

    @morbiuswilters said:

    @bstorer said:

    Java in not C++ 2.0 or something.

    I think Bjarne Stroustrup would disagree with you there.  C++ is obviously designed as a predecessor to Java.  So perhaps instead of saying "Java is C++ 2.0" we should be saying "C++ is Java 0.5".

    Wrong. The successor to C++ is C++0x, and it will suck all the joy from this world and devour our souls. The predecessor to Java is obviously Microsoft J++. It's so clear: C++ -> J++ -> Java. I don't know why Sun replaced the "++" with "ava".

     

    Wasent java suposed to be called "Oak" but that was taken so they went with the next best thing? I heard that somewhere I am not sure what the source is...



  • @bstorer said:

    Wrong. The successor to C++ is C++0x, and it will suck all the joy from this world and devour our souls. The predecessor to Java is obviously Microsoft J++. It's so clear: C++ -> J++ -> Java. I don't know why Sun replaced the "++" with "ava".

    Fail.  First there was C, then there was C+, then there was C++.   Java was supposed to be C+++ but it Sun didn't own the trademark for the letter C so they went with the name of a coffee instead.  When Microsoft made their lame, shitty rip-off of Java they went back to the original name and called it "C++++" but that was so long they had to stack the pluses into 2 rows, ergo "C#".



  • @morbiuswilters said:

    @bstorer said:

    Wrong. The successor to C++ is C++0x, and it will suck all the joy from this world and devour our souls. The predecessor to Java is obviously Microsoft J++. It's so clear: C++ -> J++ -> Java. I don't know why Sun replaced the "++" with "ava".

    Fail.  First there was C, then there was C+, then there was C++.   Java was supposed to be C+++ but it Sun didn't own the trademark for the letter C so they went with the name of a coffee instead.  When Microsoft made their lame, shitty rip-off of Java they went back to the original name and called it "C++++" but that was so long they had to stack the pluses into 2 rows, ergo "C#".

    God, you suck at programming language history. This is how it worked:


    C
    |
    C+
    |
    C++
    |
    J++
    |
    +-------------+-------------+
    | | |
    Objective C C++0x C++++
    | | |
    Subjective C | C#
    | |
    Java----------End of the World



  • @bstorer said:

    God, you suck at programming language history. This is how it worked:
    You missed a couple of nodes there:

     

                         C
    |
    C+
    |
    C++
    |
    J++
    |
    +-------------+-------------+
    | | |
    Objective C C++0x C++++
    | | |
    Subjective C | C#
    | |
    Java----------<font color="#ff0000">SSDS.NET</font>
                         |
    |
                   <font color="#ff0000">Alien invasion</font>
                         |  
                  End of the World


  • @morbiuswilters said:

    When Microsoft made their lame, shitty rip-off of Java

    Hey! Why you gotta go insulting C#? It's fun! :-D



  • @AbbydonKrafts said:

    @morbiuswilters said:
    When Microsoft made their lame, shitty rip-off of Java

    Hey! Why you gotta go insulting C#? It's fun! :-D

     

    C# is C++ with java features which only works on Windows (intended). Java's big selling point was "platform independence" and C# does not have that selling point.

     

    Firend of mine works with C# and this is a paraphrasing of his take on it:

    C# is great... except when microsoft updates. they fix a bug or 2 but then something totaly different somewhere in the oposite corner of C# breaks. So every time microsoft updates C# we all sit around and pray that everything goes ok.



  • @dlikhten said:

    C# is C++ with java features which only works on Windows (intended). Java's big selling point was "platform independence" and C# does not have that selling point.
     

    Interesting how TSMoE is running ASP.NET (C#) on Ubuntu server with Apache then. I wish someone would have told me!

     @dlikhten said:

    C# is great... except when microsoft updates. they fix a bug or 2 but then something totaly different somewhere in the oposite corner of C# breaks. So every time microsoft updates C# we all sit around and pray that everything goes ok.

    CITATION NEEDED

    I have NEVER seen this, and I have been using .NET since somewhere around 1.1

     



  • @dlikhten said:

    C# is C++ with java features which only works on Windows (intended).

     

    Wow.  Are you serious?  C# isn't much closer to C++ than Java is.  If anything it's closest to Java.



  • @MasterPlanSoftware said:

    @dlikhten said:

    C# is C++ with java features which only works on Windows (intended). Java's big selling point was "platform independence" and C# does not have that selling point.
     

    Interesting how TSMoE is running ASP.NET (C#) on Ubuntu server with Apache then. I wish someone would have told me!

     

    Dude, that's perl, not C#.  Perl is also a piece of shit language, so I can see how you got them confused.  C# is for M$ n00bs who weren't smart enough to learn Java.

     

    @MasterPlanSoftware said:

    @dlikhten said:

    C# is great... except when microsoft updates. they fix a bug or 2 but then something totaly different somewhere in the oposite corner of C# breaks. So every time microsoft updates C# we all sit around and pray that everything goes ok.

    CITATION NEEDED

    I have NEVER seen this, and I have been using .NET since somewhere around 1.1

     

    Dude, everyone knows about the C# problems, you don't need a citation for it, just check out Slashdot.  Microsoft has intentionally released several patches that broke .NET so they could sell "Service Packs".  With Linux, I don't need to pay someone for bug fixes, I just type "apt-get install bugfixes" and everything is patched instantly.  Not that Linux ever does have bugs, but it's nice to know that I won't have to pay if that day ever comes.



  • @morbiuswilters said:

    Microsoft has intentionally released several patches that broke .NET
     

    Dude, you forgot to mention the CONVICTED MONOPOLIST! 



  • @upsidedowncreature said:

    @morbiuswilters said:

    Microsoft has intentionally released several patches that broke .NET
     

    Dude, you forgot to mention the CONVICTED MONOPOLIST! 

    Sorry, I just automatically add it in my head, but I forgot to type it.  Seriously, what is up with people defending Microsoft?  They are convicted criminals.  That would be like TDWTF users defending the Nazis' merciless slaughter of millions of innocent Jews for no reason other than shame over their own inability to form a stable country.  I'm not saying M$ is as bad as the Nazis, but there are definitely some similarities between American Capitalism and National Socialism, if you're willing to open your eyes to the truth.



  • @bstorer said:

    Actually, String has its own inconsistencies, too. The fact that + is overloaded for String but not other objects is stupid.

    Everyone thinks they're more qualified to design Java than Sun is. String is a special class that's intertwined with the Java runtime. In many ways it's like a primitive. It can be expressed as a literal. It gets cached and interned by the runtime. A lot of technologies that accept primitives also accept Strings (JMS, JPA, and others I'll probably think of later). Saying "they overloaded + for Strings, so why not overload it for other objects" is like saying "you can express String literals with double-quotes, so why not come up with unique symbols for expressing all other objects as literals." It's silly to talk about String being an object without acknowledging its special nature.

    If you haven't already, feel free to show off your language design prowess over here.



  • @MasterPlanSoftware said:

    @dlikhten said:
    C# is great... except when microsoft updates. they fix a bug or 2 but then something totaly different somewhere in the oposite corner of C# breaks. So every time microsoft updates C# we all sit around and pray that everything goes ok.

    CITATION NEEDED

    I have NEVER seen this, and I have been using .NET since somewhere around 1.1

     

    Like the one where XP SP2 introduced the totally undocumented behaviour in .NET 1.x of XmlReader.Read() blocking until it gets either EOF or has 4096 bytes in its buffer. Sure, it's not a problem, unless you are trying to parse XMPP-style XML streams. And since it was undocumented, you could spend ages debugging your code and not getting why does XmlReader.Read() block. Apparently that change supposed to fix an other issue. Fortunately they fixed the thing in .NET 2.0 (or 3.x, I don't remember)

    Usually, breaking changes in the .NET Framework are rare and well-documented and I find it a quite stable platform in terms of backwards compatability.



  • I am really sorry. I never intended to start a language war, all I wanted was to point out an intresting oddity. 



  • @subanark said:

    I never intended to start a language war
     

    Yes you did. But it is ok, it happens all the time. The sidebar thrives on it.

    @subanark said:

    an intresting oddity. 

    Uh no. That is not at all what it was.

     

     



  • @spamcourt said:

    And as assignment logically follows:

       a = b      copy the value of b to a  => a == b but not a === b (except if it were this way before)
       a := b     make a equal to b => a == b and a === b

     

    In Java now, a=b makes a point to the same object as b, whereas a = b.clone() copies the object. Thus your suggestion would break backwards compatibility. (Although having some other shorthand for a=b.clone() would be useful.)



  • @CodeSimian said:

    You are reading the wrong implication into my statement "I wonder why".  I meant to imply that Java doesn't implement pointers BECAUSE OF SIMPLICITY ROBUSTNESS AND SECURITY which ties into my argument that autoboxing is not simple, because it is implicit behaviour which can be potentially confusing.  I was attempting to be sarcastic.
     

    FTFY. It's pretty much a requirement when doing memory management with garbage collection to track references. That pointers are considered "hard" or "difficult" is just a side effect.



  • @Nandurius said:

    @CodeSimian said:

    You are reading the wrong implication into my statement "I wonder why".  I meant to imply that Java doesn't implement pointers BECAUSE OF SIMPLICITY ROBUSTNESS AND SECURITY which ties into my argument that autoboxing is not simple, because it is implicit behaviour which can be potentially confusing.  I was attempting to be sarcastic.
     

    FTFY. It's pretty much a requirement when doing memory management with garbage collection to track references. That pointers are considered "hard" or "difficult" is just a side effect.

    Point taken.  I admit my argument sucked.  It was very over-simplified (pun intended).  Quite frankly, I regret going down that path.

    But read this:

    http://java.sun.com/docs/white/langenv/Simple.doc2.html 

    Any task that would require arrays, structures, and pointers in C can be more easily and reliably performed by declaring objects and arrays of objects. Instead of complex pointer manipulation on array pointers, you access arrays by their arithmetic indices. The Java run-time system checks all array indexing to ensure indices are within the bounds of the array.

    Even Sun's whitepaper focuses on simplicity, ease of use and reducing complexity.  I agree that this may just be marketing BS, but there it is. 

    Also, I would argue that a language with automatic garbage collection and no C-style pointers is simpler (there I go again) then a language with C-style pointers and manual garbage collection.  After all, as the argument sometimes goes, a good programmer should have no problem with buffer overflows and memory leaks (which are the bane of languages with manual memory management and C-style pointers).  But in reality, memory leaks and buffer overflows still happen, because obviously some code has too much complexity to manage for the best of us.

    But, I do agree there are many other motivations for Java's design besides simplicity, and I agree that "lack of simplicity" is not the best argument for disliking Java's autoboxing.  The other argument of poor design and broken abstractions is much better.  (I would argue, though, that one of the purposes of an abstraction is to simplify a difficult concept.)

     



  • It's issues like this that make testing necessary.  (Coupled with the problem that coders (and all other people) are not perfect.)

    I think the OP intended to post something that looks wrong for a couple of seconds before it becomes obvious what's really going on.  This highlights why caution is needed when programming to ensure such features are not inadvertantly used incorrectly. 

    @MasterPlanSoftware said:

    Anyway, this thread was obviously started to provoke a flamewar,
    I don't think it was.  It may not have become one if you hadn't assumed it was.@subanark said:
    Is this a Java troll?
    MPS is definitely not a Java troll.

    Hmm, seems like my point has already been made:@MasterPlanSoftware said:

    @subanark said:
    I never intended to start a language war
    Yes you did. But it is ok, it happens all the time. The sidebar thrives on it.@subanark said:
    an intresting oddity. 
    Uh no. That is not at all what it was.
    MPS, please believe that there are people in the world who have the capacity to start a thread without harbouring the intention to start a war.  I saw no such desire in the initial post.

     



  • @Eternal Density said:

    It's issues like this that make testing necessary.  (Coupled with the problem that coders (and all other people) are not perfect.)

    I think the OP intended to post something that looks wrong for a couple of seconds before it becomes obvious what's really going on.  This highlights why caution is needed when programming to ensure such features are not inadvertantly used incorrectly. 

    I haven't worked seriously in Java for over 4 years.  I've done a small amount of work in Java 1.5 and 1.6 but I certainly wouldn't consider myself an expert with the language.  However, I instanty saw the problem with the OP's post.  I admit to not knowing why the < and > comparisons worked and not knowing about the "under 128" caching "feature" of the JVM spec, but the entire thing appeared wrong anyway and it's not the type of code that I would write.  It surprises me that the first two examples work correctly, but I would never rely on that for any actual software.  So, if it took you a couple of seconds to see the problem, you must be quite a n00b at Java.  One of the very first things you learn in any book or class is that you never use operators to compare objects.  So the entire OP seems like "Java 101 for n00bs, with some strange JVM-specific behavior that is unexpected but also violates basic standards for working with wrapper classes."



  • @morbiuswilters said:

    I haven't worked seriously in Java for over 4 years.  I've done a small amount of work in Java 1.5 and 1.6 but I certainly wouldn't consider myself an expert with the language.  However, I instanty saw the problem with the OP's post.  I admit to not knowing why the < and > comparisons worked and not knowing about the "under 128" caching "feature" of the JVM spec, but the entire thing appeared wrong anyway and it's not the type of code that I would write.  It surprises me that the first two examples work correctly, but I would never rely on that for any actual software.  So, if it took you a couple of seconds to see the problem, you must be quite a n00b at Java.  One of the very first things you learn in any book or class is that you never use operators to compare objects.  So the entire OP seems like "Java 101 for n00bs, with some strange JVM-specific behavior that is unexpected but also violates basic standards for working with wrapper classes."
     

    Well, I guess where the problem lies depends on your POV.  Based on my oldish Java knowledge, I didn't expect the code to compile at all (and it doesn't under 1.4 and earlier).  Everybody who knows a little bit of Java realizes objects and primitives are not interchangeable.  But along comes this new autoboxing feature which says sometimes objects and primitives are interchangeable, (e.g. not in cases where it would break backwards compatibility.)

    From your POV (and others), the OP's code is stupid, therefore there's no problem (i.e. "You should never write that kind of code, what are you complaining about?").  From my POV, I don't care whether the code is stupid or not.  I think the language should be designed so nobody has to ask "How come the '<' and '>' operators work in this case, but not the '!=' and '==' operators?" regardless of whether it's a stupid question or not. 

    To me, the WTF is not that anyone would rely on that behaviour (they wouldn't), but that one has to ask why does it work that way?  IMO, that was whole point of the OP.

    As for me, I learned a little bit about Java (some of which I had forgotten years ago), so I have no complaints about this thread.


Log in to reply