Please stop saying Java sucks(blog.smartbear.com)
blog.smartbear.com
Please stop saying Java sucks
http://blog.smartbear.com/programming/please-stop-staying-java-sucks/
13 comments
I can believe that a lot of Java devs are not keeping up, but the kerfuffle around that particular Railsconf keynote is a poor example -- I'm pretty sure lots of cutting-edge machine learning researchers, Haskell developers, and so forth also weren't following the gossip in the technical community around a particular tool set that they don't happen to use.
I've seen communities which start to think they're smarter than everyone else because those other people don't get the insiders' inside jokes. It's usually not a good sign for the community...
I've seen communities which start to think they're smarter than everyone else because those other people don't get the insiders' inside jokes. It's usually not a good sign for the community...
Java isn't capable, however, of high levels of abstraction without various surrounding crufts, however. That is why it sucks. It's not simply a matter of "more lines", it's the additional cognitive overhead reading those lines demands, and the tooling required to make it suck less.
Did you just call jython, jruby, groovy, and all of the other dynamic JVM languages cruft?
Or maybe you don't consider them high levels of abstraction... if that's the case might as well not consider inheritance, interfaces, dynamic proxies, classloaders, and annotations while we're at it.
Or maybe you don't consider them high levels of abstraction... if that's the case might as well not consider inheritance, interfaces, dynamic proxies, classloaders, and annotations while we're at it.
I read it as you have to add in a bunch of useless boilerplate to do things like pass in an anonymous class to Collections.sort because of a lack of Lambda's (for a stupidly long time at least).
No, I didn't: none of those are Java. They're Jython, JRuby, Groovy, and the other JVM languages.
We're discussing Java-the-language. Not the JVM. And without various surrounding crufts you don't have an expressive, dynamic, malleable language with high levels of abstraction.
Lambdas help, but do not solve, Java's impoverished model of abstraction.
We're discussing Java-the-language. Not the JVM. And without various surrounding crufts you don't have an expressive, dynamic, malleable language with high levels of abstraction.
Lambdas help, but do not solve, Java's impoverished model of abstraction.
All of the things I listed are part of the Java language and standard library.
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/P...
http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoad...
http://docs.oracle.com/javase/7/docs/api/java/lang/annotatio...
etc
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/P...
http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoad...
http://docs.oracle.com/javase/7/docs/api/java/lang/annotatio...
etc
I never said it didn't have those things; I'm not sure why you're still talking about them.
I said Java has an impoverished model of abstraction, and without external tools (byte-code manipulation, libraries, etc) it still doesn't.
Then you brought up not-Java, which I also didn't talk about. You brought those up because those do have better models of abstraction than Java does, which effectively concedes my point.
I said Java has an impoverished model of abstraction, and without external tools (byte-code manipulation, libraries, etc) it still doesn't.
Then you brought up not-Java, which I also didn't talk about. You brought those up because those do have better models of abstraction than Java does, which effectively concedes my point.
>Java isn't capable, however, of high levels of abstraction without various surrounding crufts, however.
Well, Go is even worse in this regard, and yet people jump all over it.
Well, Go is even worse in this regard, and yet people jump all over it.
Go at least has the ability to be fast. And compact enough to fit in your head. And approach a specific set of problems. For what it originally set out to do, it actually works pretty well.
What's Java's supposed purpose THIS week, again? First it was making web pages interactive, but it turned out that nothing ever worked in Java web applets except security flaws. Then we were told that Java had always been meant for making desktop apps, but it turns out that nobody in the late 1990s and early 2000s wanted to work with shitty purple quasi-windows designed to cater to the lowest-common-denominator X systems from 1982. Then we were told that Java had always been intended to take over the low-power, low-resource embedded space, but Scott McNealy's speech about that was hard to hear over the sounds of millions of embedded developers laughing so hard that they all shit their pants. I suppose you can argue that it works okay as a quasi-embedded platform today due to Android, but that's only because the idea of "embedded" has expanded, and because the Android boys swapped out the JVM horror show for something that didn't suck dick for a nickel and give four pennies in change.
Shit, what IS Java's one true purpose supposed to be these days? It's hard to keep track. Oh, that's right-- it's for WEB development. Or at least, that was Java's always-all-along-never-did-we-deviate-from-this-concept purpose according to SUN, right up until they found a buyer for the bloated corpse of their once-mediocre company. The original intent of Java to be used as REST-aware web dev platform totally shows in its design. That's what they were thinking of ALL ALONG. Yep. Yes, sir. No doubt about it.
Go, on the other hand, has no defined market, application, or purpose where it can solve any specific problems, and will therefore have to only be quasi-popular because Google is pushing it harder than Plus-- not because its developers actually LIKE it.
What's Java's supposed purpose THIS week, again? First it was making web pages interactive, but it turned out that nothing ever worked in Java web applets except security flaws. Then we were told that Java had always been meant for making desktop apps, but it turns out that nobody in the late 1990s and early 2000s wanted to work with shitty purple quasi-windows designed to cater to the lowest-common-denominator X systems from 1982. Then we were told that Java had always been intended to take over the low-power, low-resource embedded space, but Scott McNealy's speech about that was hard to hear over the sounds of millions of embedded developers laughing so hard that they all shit their pants. I suppose you can argue that it works okay as a quasi-embedded platform today due to Android, but that's only because the idea of "embedded" has expanded, and because the Android boys swapped out the JVM horror show for something that didn't suck dick for a nickel and give four pennies in change.
Shit, what IS Java's one true purpose supposed to be these days? It's hard to keep track. Oh, that's right-- it's for WEB development. Or at least, that was Java's always-all-along-never-did-we-deviate-from-this-concept purpose according to SUN, right up until they found a buyer for the bloated corpse of their once-mediocre company. The original intent of Java to be used as REST-aware web dev platform totally shows in its design. That's what they were thinking of ALL ALONG. Yep. Yes, sir. No doubt about it.
Go, on the other hand, has no defined market, application, or purpose where it can solve any specific problems, and will therefore have to only be quasi-popular because Google is pushing it harder than Plus-- not because its developers actually LIKE it.
>Go at least has the ability to be fast.
Err, Java is typically faster than Go. And with much better GC to top.
>And compact enough to fit in your head.
It's not like Java is Haskell either. Any enterprise slob can handle it. C# has 4 times Java's features.
>What's Java's supposed purpose THIS week, again?
To be a general purpose programming language?
>First it was making web pages interactive
That hasn't been the case for 15 or so years. Ever since 2000 it was server side enterprise and web apps, and some device stuff thrown in for good measure (which was one of Java target's even before applets).
Err, Java is typically faster than Go. And with much better GC to top.
>And compact enough to fit in your head.
It's not like Java is Haskell either. Any enterprise slob can handle it. C# has 4 times Java's features.
>What's Java's supposed purpose THIS week, again?
To be a general purpose programming language?
>First it was making web pages interactive
That hasn't been the case for 15 or so years. Ever since 2000 it was server side enterprise and web apps, and some device stuff thrown in for good measure (which was one of Java target's even before applets).
Java is pretty fast. Not sure how saying "Y is worse" is particularly meaningful.
because they probably spend most of their time in a cubicle thinking that these new-fangled technologies will die someday, and we can all go back to writing crap like we did in 1999.
That is exactly the singular reason I don't pay attention to DHH's brain farts. I guess you got me.
That is exactly the singular reason I don't pay attention to DHH's brain farts. I guess you got me.
Java is fine. It did lag a little behind there for a few years, but the last two Java releases have really pulled things together.
I will say C# is still my preferred language just for quality of life reasons, and I also feel like Java has been largely relegated to either web-backend or enterprise desktops. There is no practical way to deliver a Java application to an consumer now, Java Applets are "dead" and running Java on the desktop is a pain. Minecraft is likely the only reason any non-business user has Java still installed.
But saying Java is "only" good for web-backend stuff is kind of like saying a car is "only" good for driving. That's where the majority of new development currently happens and it has a very bright future. Java on Tomcat delivers that experience just fine (although C# w/MVC is still my poison, again for quality of life stuff).
I will say C# is still my preferred language just for quality of life reasons, and I also feel like Java has been largely relegated to either web-backend or enterprise desktops. There is no practical way to deliver a Java application to an consumer now, Java Applets are "dead" and running Java on the desktop is a pain. Minecraft is likely the only reason any non-business user has Java still installed.
But saying Java is "only" good for web-backend stuff is kind of like saying a car is "only" good for driving. That's where the majority of new development currently happens and it has a very bright future. Java on Tomcat delivers that experience just fine (although C# w/MVC is still my poison, again for quality of life stuff).
Could you explain the "quality of life" bit? Are you saying that if you programmed in Java life would be hellish?
This article summarises the differences:
https://msdn.microsoft.com/en-us/library/ms836794.aspx
Although it is a little out of date in some areas (for both languages).
C# has been stealing from F# for several versions now, so we get all kinds of nice shorthand for accomplishing sometimes complex operations.
Although it is a little out of date in some areas (for both languages).
C# has been stealing from F# for several versions now, so we get all kinds of nice shorthand for accomplishing sometimes complex operations.
Off the top of my head:
* A half-decent type system
* No half-baked primitive / object distinction
* The `as` operator
* Various operators related to null
* Ability to distinguish if something is nullable or not, and to have nullable and non-null references
* The `checked` keyword
* Operator overloading
* Properties
* Syntactic sugar w.r.t. getters and setters
* out & ref parameters
* struct support
* unsigned values
All of these things are major pain points in Java. Some of them can be overcome by running external tools, some of the time. Hopefully.
* A half-decent type system
* No half-baked primitive / object distinction
* The `as` operator
* Various operators related to null
* Ability to distinguish if something is nullable or not, and to have nullable and non-null references
* The `checked` keyword
* Operator overloading
* Properties
* Syntactic sugar w.r.t. getters and setters
* out & ref parameters
* struct support
* unsigned values
All of these things are major pain points in Java. Some of them can be overcome by running external tools, some of the time. Hopefully.
Meh, I like Java. Like, I actually enjoy programming in it. Some key reasons:
1. IDEs are not a crutch. They're a useful tool. Anyone who talks about expressiveness or efficiency in Ruby but discounts IDE help is a hypocrite. You learn the tools you have. Refactoring large methods, extracting interfaces, mass renaming with guaranteed safety -- those things actually matter when you learn to use them.
2. Ant is dead. Hibernate is dying. Spring XML config is largely dead. Much like the perf argument, most of the bad impressions people have of it are based on years-old issues.
3. Tools like Spring Boot and Dropwizard have made it so a Java REST service is smaller than a RoR one.
4. Gem upgrades can be backwards incompatible, so once your app is of a certain size, your framework support becomes very rigid and brittle.
5. Twitter left Ruby because of perf issues. drops mic
6. Active Record ~= Hibernate. Hibernate can be configured with annotations, so leave the XML out of this. You still have n+1 and over-selection of fields by default.
7. Global interpreter lock. 'Nuff said.
8. The actual argument used by DHH wrt performance was, 'Ruby is fast enough' -- if the Java community tried that, it would be an endless mocking parade.
I could go on, but won't. I don't care if others leave Java, just means more work for me. Hell, replacing shitty rails apps and replacing them with reasonable java apps is a good consulting business :)
1. IDEs are not a crutch. They're a useful tool. Anyone who talks about expressiveness or efficiency in Ruby but discounts IDE help is a hypocrite. You learn the tools you have. Refactoring large methods, extracting interfaces, mass renaming with guaranteed safety -- those things actually matter when you learn to use them.
2. Ant is dead. Hibernate is dying. Spring XML config is largely dead. Much like the perf argument, most of the bad impressions people have of it are based on years-old issues.
3. Tools like Spring Boot and Dropwizard have made it so a Java REST service is smaller than a RoR one.
4. Gem upgrades can be backwards incompatible, so once your app is of a certain size, your framework support becomes very rigid and brittle.
5. Twitter left Ruby because of perf issues. drops mic
6. Active Record ~= Hibernate. Hibernate can be configured with annotations, so leave the XML out of this. You still have n+1 and over-selection of fields by default.
7. Global interpreter lock. 'Nuff said.
8. The actual argument used by DHH wrt performance was, 'Ruby is fast enough' -- if the Java community tried that, it would be an endless mocking parade.
I could go on, but won't. I don't care if others leave Java, just means more work for me. Hell, replacing shitty rails apps and replacing them with reasonable java apps is a good consulting business :)
> Twitter left Ruby because of perf issues.
That's not completely true. Some parts of the stack were written in Scala, etc., but to my knowledge, much of the front end is still Ruby.
That's not completely true. Some parts of the stack were written in Scala, etc., but to my knowledge, much of the front end is still Ruby.
Hear, hear! Is Java the right tool for everything? No, but for large code bases, it is miles easier to dive into a codebase, and the tooling is so much better than anything else I've seen that's not Visual Studio (as much as I'm not a MS fan, VS is really nice).
Is Java perfect? No, but it gets a whole lot of things not-wrong. More reasons: https://drew.thecsillags.com/Why-Java/
Is Java perfect? No, but it gets a whole lot of things not-wrong. More reasons: https://drew.thecsillags.com/Why-Java/
Funny how people get riled up over stuff like this. The article is from 6 years ago and you still hear the same comments like "the _____ sucks but the ____ is fine" (ecosystem|language,types|jvm
etc.)
The only way to have a healthy debate about a language is to have context: if you are building an integration between a custom app with a RDBMS that has to send data to an ERP system in XML, and there are specs with interfacing the ERP in Java, C#, C++ are you going to argue that Haskell or Lisp is better?
If you have to put a simple web application together quickly as a working prototype are you going to choose Ruby/Rails, Perl, Java/JSP, etc.? It probably doesn't matter technically but does matter when it comes to the experience of the people building it.
Just debating languages against each other in some sort of "cage match" is sort of ridiculous.
The only way to have a healthy debate about a language is to have context: if you are building an integration between a custom app with a RDBMS that has to send data to an ERP system in XML, and there are specs with interfacing the ERP in Java, C#, C++ are you going to argue that Haskell or Lisp is better?
If you have to put a simple web application together quickly as a working prototype are you going to choose Ruby/Rails, Perl, Java/JSP, etc.? It probably doesn't matter technically but does matter when it comes to the experience of the people building it.
Just debating languages against each other in some sort of "cage match" is sort of ridiculous.
I think when I've heard people saying Java sucks, they mean its type system allows defects that the type system of F# or Scala can prevent. Those reasons given for Java being better than Python or Ruby are also why F# is better than Java.
It's a lot more than that. For example, it's really annoying to define new types in Java.
Could you be more specific? How is it really annoying to define new types in Java?
You have to manually define its constructor, manually provide getters if you want the value to be immutable, put each class in a separate file (or namespaced inside another class), and if your type has finitely many alternatives you have to set up the whole visitor pattern thing. Compare that with C#'s properties and readonly, Scala's case classes, Swift's enum types.
Making immutable structures in Java truly does suck... this is the most valid complaint that I've heard in a long time about the language.
It would be extremely easy to implement properties as syntactic sugar in the language or via built-in annotations without changing the class file spec at all.
It would be extremely easy to implement properties as syntactic sugar in the language or via built-in annotations without changing the class file spec at all.
Disclaimer: I come from C++ and PHP world, but in the last few years, have been working in Java after a long gap.
So here are the pros and cons of Java I see (not comprehensive but somethings that I tend to care about):
Pros:
1) The strongly typed features does help in finding potential bugs during compile time.
2) The Generics and Container frameworks seems fairly sane when compared to the complexity of C++ templates.
3) Concurrency features are nicely standardized now - Executor framework, concurrent container frameworks and so on.
4) In short, 'stock java' (without all the heavy-weight frameworks) seem nice comfortable and sane to work with.
Cons:
1) Fairly large and legacy XML-driven frameworks like Spring and Hibernate is a huge time-sink to figure out all their intricacies, not to mention very hard to debug things esp. when some 'business logic' resides in these mysterious XML incantations.
2) While not really a Java problem, but due to these humongous frameworks, there is a tendency to build giant war files with code and configs all bundled together. Need to make a config change? Check it in some xml file, and then build to deploy wars/jars. It takes some work to separate code from configs, and convincing traditional Java engineers to move away from this model - i.e. check configs separately, deploy them independently, restart servers etc.. without any need to build and deploy process.
3) Legacy app-server based architectures where there is apache in the front with IPC overheads to a Java app-server.
The way I get around some of the cons is to convince the engineers to sparingly use the frameworks (just enough to get some basic routing rules to map urls to controller entry points in the MVC setups), use more lightweight servers like Jetty (directly listening on socket ports), esp. when it is just handling some API requests, and sticking with JSON as the payload format.
It is been a challenge but I have had success in using Java in very limited ways, and decoupling it from serving web (jsp) pages and so on.
So here are the pros and cons of Java I see (not comprehensive but somethings that I tend to care about):
Pros:
1) The strongly typed features does help in finding potential bugs during compile time.
2) The Generics and Container frameworks seems fairly sane when compared to the complexity of C++ templates.
3) Concurrency features are nicely standardized now - Executor framework, concurrent container frameworks and so on.
4) In short, 'stock java' (without all the heavy-weight frameworks) seem nice comfortable and sane to work with.
Cons:
1) Fairly large and legacy XML-driven frameworks like Spring and Hibernate is a huge time-sink to figure out all their intricacies, not to mention very hard to debug things esp. when some 'business logic' resides in these mysterious XML incantations.
2) While not really a Java problem, but due to these humongous frameworks, there is a tendency to build giant war files with code and configs all bundled together. Need to make a config change? Check it in some xml file, and then build to deploy wars/jars. It takes some work to separate code from configs, and convincing traditional Java engineers to move away from this model - i.e. check configs separately, deploy them independently, restart servers etc.. without any need to build and deploy process.
3) Legacy app-server based architectures where there is apache in the front with IPC overheads to a Java app-server.
The way I get around some of the cons is to convince the engineers to sparingly use the frameworks (just enough to get some basic routing rules to map urls to controller entry points in the MVC setups), use more lightweight servers like Jetty (directly listening on socket ports), esp. when it is just handling some API requests, and sticking with JSON as the payload format.
It is been a challenge but I have had success in using Java in very limited ways, and decoupling it from serving web (jsp) pages and so on.
The biggest problem I have with Java is that it is handhold-y in ineffective ways.
It doesn't have automatic getters and setters, because they obscure the code that runs. Except that in practice everything ends up with getters and setters precisely because it means it can obscure the code that runs - namely, so you can add behavior without having to change the public interface. Which means in practice it's just more boilerplate and more opportunity for typos.
Ditto with operator overloading, interfaces, default arguments, multiple inheritance, dynamic types...
It doesn't have automatic getters and setters, because they obscure the code that runs. Except that in practice everything ends up with getters and setters precisely because it means it can obscure the code that runs - namely, so you can add behavior without having to change the public interface. Which means in practice it's just more boilerplate and more opportunity for typos.
Ditto with operator overloading, interfaces, default arguments, multiple inheritance, dynamic types...
I have the feeling that the "Java sucks" outcries are not so loud anymore. Java improved significantly over the last few years, the frameworks are better and more lightweight these days (compare Java EE 7 with J2EE ...). And Java has probably the best tooling available. Plus there are some migration stories of companies moving away from Ruby, Python or other scripting languages.
So, all in all Java is a fine technology and you can use the solid foundation with more convenient and concise languages like Scala and Kotlin.
So, all in all Java is a fine technology and you can use the solid foundation with more convenient and concise languages like Scala and Kotlin.
The reality is that if Java was a useless language, it wouldn't be the most used programming language in the world. It's not the right tool for every task but more people in the world find it the right tool for their job than any other language. There's a reason for that and it's not that a now defunct company funded its development decades ago.
Java sucks.
But seriously, every language has its pros and cons. Java is a powerful, fast language, but verbose and often wielded like a hammer IMHO.
But seriously, every language has its pros and cons. Java is a powerful, fast language, but verbose and often wielded like a hammer IMHO.
I'm curious how you mean "powerful" here.
> AutoCAD is going to be big, Quickbooks is going to be big, FireFox is going to be big
1. you probably aren't writing those. 2. Even if you are, you probably aren't writing them in Java.
The problem is the reason why you have to write so many lines in Java. Annoying checked exceptions, lack of expressiveness, boilerplate.
Strong type checking? great. prevents whole swaths of errors.
> Move code around, change signatures, add a function to an interface, and I know nothing is broken. Python can’t.
True, now how painful is it without the IDE?
> It’s true that in Java you tend to have lots of filler code
right and that sucks. The reason that few lines of code is nice isn't just the chances of bugs occuring. It's also nice because it means that I can pack in logic into a smaller, more readable, space. All that other stuff in java doesn't really do much of anything, it is just there (mandatory javadoc on a method called boolean isFooFrobulated(Foo foo), yay so useful!). It means I have to write it, have to maintain it, have to read through it when looking for a bug.
Consider how many java haters actually like C#. It just adds in better tooling to reduce the amount of stupid boilerplate code you have to write. It adds a nice layer of sugar on top that makes things far more pleasant.
1. you probably aren't writing those. 2. Even if you are, you probably aren't writing them in Java.
The problem is the reason why you have to write so many lines in Java. Annoying checked exceptions, lack of expressiveness, boilerplate.
Strong type checking? great. prevents whole swaths of errors.
> Move code around, change signatures, add a function to an interface, and I know nothing is broken. Python can’t.
True, now how painful is it without the IDE?
> It’s true that in Java you tend to have lots of filler code
right and that sucks. The reason that few lines of code is nice isn't just the chances of bugs occuring. It's also nice because it means that I can pack in logic into a smaller, more readable, space. All that other stuff in java doesn't really do much of anything, it is just there (mandatory javadoc on a method called boolean isFooFrobulated(Foo foo), yay so useful!). It means I have to write it, have to maintain it, have to read through it when looking for a bug.
Consider how many java haters actually like C#. It just adds in better tooling to reduce the amount of stupid boilerplate code you have to write. It adds a nice layer of sugar on top that makes things far more pleasant.
> 1. you probably aren't writing those. 2. Even if you are, you probably aren't writing them in Java.
You probably also don't have teams as big as Autodesk or Quicken, therefore you'd better have a language that helps prevent breakages. Java is a good match for that.
> True, now how painful is it without the IDE?
Why would you do that? Because you like working without good tools? Text editing is but a very tiny aspect of software development.
You probably also don't have teams as big as Autodesk or Quicken, therefore you'd better have a language that helps prevent breakages. Java is a good match for that.
> True, now how painful is it without the IDE?
Why would you do that? Because you like working without good tools? Text editing is but a very tiny aspect of software development.
Where things start to suck is what seems to surround Java. Years and years of XML configs, Maven and Ant processes. Devs whom haven't been allowed to read about new advances.... I was at a Java user group about a year ago when Venkat Subramaniam came to speak about functional programming. This was right around the time when DHH made his assertion about unit testing. Venkat made a joke like, "and as we learned this week, we no longer need to test our code". No one got the joke. A room full of at least 200 developers and no one got it... because they probably spend most of their time in a cubicle thinking that these new-fangled technologies will die someday, and we can all go back to writing crap like we did in 1999. (Other fun assertions from that user group had to do with JSON being horrible and XML being a far better format for web communication)
It highlighted the problem for me. While Twitter engineers are doing really cool things with Java, many are mired in these huge monolithic apps that take hours to build and even longer to deploy. And much of this stuff is stored in SVN... with no unit tests. It's the culture. They look at front-end developers with disdain... with their GitHub accounts and Vim/Tmux setups. Java doesn't suck. The culture that has grown around it does.