• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Back to school rant

 
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<rant>
So anyway, right now I'm trying to resurrect my ancient Java development skills as I'm about to start a job on a thoroughly enterprised Java project where I'll need to know about all that SpringEE Mavernate stuff that has taken over the world while I was in suspended animation after my last significant Java project about 10 years ago (I did lots of zero-fun stuff with EJB 1.1, that's how long ago it all was). Admittedly, this will involve quite a learning curve but that's OK with me (and my new employer thankfully), so I'm warming up beforehand by working through potentially relevant tutorials etc.

But after years of database-centric development (mmm, lovely data...) and several months poking around the fringes of functional programming (mmm, lovely functions...) or tinkering with dynamic languages like Python or Groovy, I guess I've lost touch with the core philosophy of the Java heartlands. So I just have to ask:

HOW THE &%$# DOES ANYBODY EVER GET ANYTHING DONE IN JAVA?

You have all these rolling hectares of XML POMs, XML Spring configs, XML Ant tasks, XML Hibernate configs etc etc to bolt together even before you can even get started. Then you have all that freaking boilerplate you have to tell Java before it will do anything - getters/setters for your bean properties, telling Java the data-type about eight times every time you mention even the vague possibility of considering looking at a variable or method, package directories nested so deep the bottom layer is on the quantum scale, about a million different JARs to put in your classpath (or into your POM) before you can actually access any libraries. Yes, I know the IDE can do some of this, but I still need to know what it's doing in the background, so right now I'm doing this stuff by hand.

Eventually you succeed in implementing your little domain class and some tests to go with it (and I do like JUnit - mmmm lovely automated testing...), so now you want to do crazy things like, I dunno, compare two objects to see if they're the same logical instance - but of course first 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? Would it have been too hard to come up with some default semantics around this kind of thing instead of just throwing a fit and vomiting up 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 dunno. 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. I expected hover-boots, dammit!

OK, it's just a rant. Got to knuckle down and (re-)learn this stuff so I can earn my daily bread, but boy, is Java proving hard to love right now...
</rant>
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
n00b
 
chris webster
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jelle Klap wrote:n00b


They're playing my song:
 
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What gives you the idea that anyone is productive using Java?

The sad reality is that Java is a nice, small, clean language. I still have my version 1 copy of Java in a Nutshell. Its a tiny book. While later versions of the book, reflecting later versions of the language are bigger, Java is still a small language.

Except for a few misguided and brain-dead features, such as generics, its still simple. Perhaps too simple.

What is hideous are the libraries that you must use to do any real world work. Nearly any real world work will include a half dozen or more libraries that were designed separately and have totally different philosophies. Thus, you have to learn a half dozen or more separate approaches to the problem. Another joy is that libraries and their philosophies aim to solve specific levels of problems. 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.

I'm a big fan of @Bear's Frontman, because it was specifically designed to do very little. It does what it aims at well, but has minimal stuff. You can even use it without any XML configuration files. Hallelujah.

I feel your pain. As I've written many times here, I see Java as being at the end of its useful life. Bring on Scala and other languages that run on the JVM without the legacy of Java, the nice, simple, small language.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Thank goodness for that!

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?



You don't have to worry about pointers and memory locations for equality. You DO have to tell Java what you consider equality for your class, and that's a good thing.

Sure, the language could have had == do equals() semantics, but that's just shorter writing of the tests. You still have to implement what's behind ==.

Oh, sure, the default could have been "compare all the fields for equality," but in my experience, that's the minority of the equals() methods I write. It maybe would have still been a reasonable default, but if I want it, my IDE will generate it for me and I'll never have to think about it again unless I add or remove members.

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.

What can you do if it's null anyway? Supply some arbitrary value to use instead? If null is a valid value, it usually has its own semantics that your logic dictates you have to test for anyway (i.e., not a language issue), and if it's not a valid value, then throwing NPE is the right thing to do.

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?



Yes, clearly you are much more knowledgable about the One True And Correct Way to design a programming language than the PhD who was the driving force behind the original Java and the team under him. I'm sure they never thought of any of those things you're complaining about, and they had no reason whatsoever for making the choices he did. And clearly they had infinite resources and time and never had to make a compromise.

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.



At my last job, I worked on a tool to monitor and manage voice and data networks for load, quality, faults, etc. Yes, there was a lot of drudgery and tedium involved, but it's nothing compared to the drudgery and tedium that would be involved for the people that would have had to do all that stuff manually if such a tool didn't exist. And of course, my one-time drudgery and tedium can offset an amount of others' drudgery and tedium (not to mention mistakes) that was limited only by their willingness to pay for the software and the hardware to run it on.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Yeah, it sucks at the hard stuff. But I find that for the simple-but-tedious stuff, it makes it less tedious while keeping it simple.
 
Pat Farrell
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


Gotta go with @Jeff here. I never catch a NPE. I place Google Guava's Precondition.notNull() test on all parameters to all methods. I use their tables, maps, sets that do not allow NULL values in them. If my code blows up on a NPE, its a sign of seriously bonked code.

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

I also use Guava's Optional return object, so you can clearly see when the method is returning a null value.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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



I like the fact that if something that I'm counting on being set isn't set, the runtime lets me know in no uncertain terms. I'd rather have it blow up at the source than just quietly misbehave 10 steps down the line.
 
chris webster
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the comments, guys - far more thoughtful than a few short-fuse rants popped off my stack on MD could be expected to deserve! Have to bow to your greater experience on most of those points, but 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.

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).

Meanwhile, it's back to the future for me. No hoverboots, so I guess a Delorean will have to do...

Cheers,
Chris
 
Sheriff
Posts: 28371
99
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There's a lot of people who are better language architects than me who think that checked exceptions are evil. Me, I'm just a plumber and I work with the tools I'm given.

But Eclipse takes care of that sort of thing for me. When I write a line of code which throws a checked exception it underlines and lets me either wrap a try-catch block around it or add "throws Whatever" to the containing method's signature. Hard-core typing not required.
 
Pat Farrell
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).



The Google Guava libraries are just another library that you use to write normal Java. They are free, open source, etc. plus well documented and tested. The key for me is that they are used by Google in zillions of lines of production code, so they really work. For example, their ImmutableList and ImmutableSet classes are, just by themselves, a great way to reduce bugs, and as easy to use as the normal Java included ArrayList or HashSet classes.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

chris webster wrote:I still think the whole declaring-exceptions-everywhere thing was old long before Java came along



There's a large camp of people who agree with that sentiment. Personally, I'm kind of on the fence. On the one hand, I like that a method has to tell me what kinds of things can go wrong, so that I can know at compile time what I might have to handle, and can handle different problems as appropriate. At least that's the theory. It falls down in two major ways.

1) The vast majority of the time, all I do is either declare those same exceptions myself, and bubble them up to the next layer, or else wrap and rethrow them. Either way (especially the second one), it leads to a lot of extra stuff that clutters up my code and doesn't actually accomplish anything except keep the compiler happy.

2) Now that there's a large movement to do away with checked exceptions, it will be more common for libraries I might want to use to turn existing checked exceptions into unchecked, and to only use unchecked exceptions for the ones they define themselves. In other words, the "they have to tell me what can go wrong" principle only applies to code that agrees with the philosophy of checked exceptions.

and nulls are often handled via "truthiness" conventions in other languages. Whatever.



I'm sure there are more convenient ways of dealing with null that are just as valid as what Java does. I guess I just don't see anything wrong with how Java does it, and it's never really an issue for me, except when I screw up and write buggy code. But then, I used to just accept C's pointers as a matter of course too.
 
Pat Farrell
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeff Verdegan wrote:I used to just accept C's pointers as a matter of course too.



Don't forget C's memory leaks. I may grump about Java, but there is no way that business programmers can do C properly. Thar be dragons.
 
Rancher
Posts: 1776
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good luck on your new job, Chris. Hope you do well!
 
chris webster
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Pat:
Yeah, I'll definitely look at those libraries for my own use, but the place I'm going to be working is *very* cautious about approving even a simple Java library for use in their application. I've worked there in the past and I couldn't even get approval to run Groovy on my PC for prepping some ad hoc data outside the application, so trying to plug a new library into the application will definitely scare the horses.

@Jeff: But then, I used to just accept C's pointers as a matter of course too.
You are clearly a Vulcan philosopher!

@John: Thanks!
 
Pat Farrell
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

chris webster wrote: is *very* cautious about approving even a simple Java library for use in their application.



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.

How far away would you have to move so you could work for a PHB with more between his ears? Next city? next state? next country?
 
chris webster
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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, they use quite a few open source libraries - they're a J(2)EE shop after all. It just takes them a *long* time and a lot of meetings to decide to do anything different (it's a government organisation), and often any idea you have is obsolete by the time a decision is made one way or the other. I don't want to be too critical - they're decent folk, they have their distinctive way of doing things and they've offered me a job after all - and I I think I need to get my feet under the desk there first, before I start thinking about launching any crusades. Or just adopt the Grace Hopper strategy wherever possible!
 
Pat Farrell
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

chris webster wrote: It just takes them a *long* time and a lot of meetings to decide to do anything different


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.

I quit working for them, even though they were paying me lots of money and they liked me. I could not stand it. Its better to pick tools using a dartboard than suffer from six months of analysis paralysis.
 
chris webster
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


I feel your pain! I wrote a small application at this place to provide some basic but important functionality that was simply never going to get implemented through their cripplingly slow Java development process. I did it using a tool that cost nothing and was already installed and being used in-house, but was not part of their standard tool-set. The tool took a few days to learn (a monkey could do it), and the app took just a few weeks to design, implement, test, document and package up for deployment. But the meetings and discussions went on for about 6 months to the best of my knowledge - my contract ended before they actually deployed the app (not sure they ever did).
 
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
reply
    Bookmark Topic Watch Topic
  • New Topic