No more Blub for me, thank you, Vicar.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Jelle Klap wrote:n00b
No more Blub for me, thank you, Vicar.
chris webster wrote:you have to run around implementing equals() and hashCode() methods because - as I recall - Java does not regard the concept of "equality" out-of-the-box in the same way as human beings do.
Question to Java language designers: which do you think is more likely, (A) I want to compare two Customer objects to see if they contain the same information, or (B) I don't give a rat's @$$ about their contents but I *really* care about their object references? I thought the whole point of Java was I didn't have to worry about $#@$ing pointers and memory locations any more?
Oh, and does everything in Javaland have to check for an NPE?
And what's with the whole business of having to declare potential exceptions everywhere all the time anyway? I mean, how much £$*#ing typing practice does anybody need in one lifetime?
I thought the idea was that computers would take over all this drudge-work for us and leave us all free to think lofty thoughts like Vulcan philosophers, or at least free to play with cool toys instead.
Pat Farrell wrote:You mention Hibernate. Its just a layer on JDBC. It can make some simple uses of a DBMS somewhat simpler. But it does nothing to help the serious problems, the seven way left joined retrieval. I fail to understand why anyone uses it, as it makes stuff that was already simple only marginally better, but offers no help at all to the really hard stuff.
Jeff Verdegan wrote:
chris webster wrote:Oh, and does everything in Javaland have to check for an NPE?
If you're catching NPE, you're usually doing it wrong. NPE indicates a bug in your code. There are only certain special situations where it's appropriate to catch it, and even then you'd usually be catching RuntimeException, Exception, or Throwable, not specifically NPE.
If you mean testing for null, with == null or != null, then, again, if the semantics of your method are that the value is not allowed to be null, document it and don't bother checking, let the NPE be thrown naturally to tell the caller he has a bug.
Pat Farrell wrote:
I do think that in hindsight, Java's insistance on blowing up and throwing a NPE is a bad design. I like JavaScript's approach here much better. They simply let NULL.foo() evaluate to NULL
No more Blub for me, thank you, Vicar.
chris webster wrote:Good tip re. the Google libraries too, although I reckon my workplace will probably be reluctant to look at new-fangled stuff like that (and Scala/Clojure/Groovy etc are completely out of the question).
chris webster wrote:I still think the whole declaring-exceptions-everywhere thing was old long before Java came along
and nulls are often handled via "truthiness" conventions in other languages. Whatever.
Jeff Verdegan wrote:I used to just accept C's pointers as a matter of course too.
No more Blub for me, thank you, Vicar.
chris webster wrote: is *very* cautious about approving even a simple Java library for use in their application.
Pat Farrell wrote:So what do they do? Do they re-implement key libraries, such as Apache's HTTP client, themselves? The whole point of OO programming is to get software reuse. That means using libraries.
No more Blub for me, thank you, Vicar.
chris webster wrote: It just takes them a *long* time and a lot of meetings to decide to do anything different
Pat Farrell wrote:I worked for a large, government-sponsored entity. They would have interminable meetings to decide between using any one tool. Not just one meeting either, but weekly meetings over months. Big meetings too, with 40+ folks in them.
No more Blub for me, thank you, Vicar.
passwords must contain 14 characters, a number, punctuation, a small bird, a bit of cheese and a tiny ad.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|