10 ms·

Java Doesn’t Suck

187 points by craigkerstiens 12y ago

davesque 12y ago
As a side note, I can still remember how nice it felt to use Java in the mid-nineties coming from C++.
applecore 12y ago
I think an important lesson for web application development—mentioned in the article—is keeping the server stateless, moving state into the client, and using a real middleware like Redis for the session cache.
shadeless 12y ago
Someone could argue that Java and PHP suck because there are a lot of people who use them wrongly. Linus Torvalds made a similar argument for not using C++: http://article.gmane.org/gmane.comp.version-control.git/57918/ http://article.gmane.org/gmane.comp.version-control.git/5791...
- serve_yay 12y ago
  I would agree with that, though perhaps more about PHP than Java. We like to say "use the right tool for the job" and "you can write bad code in any language", but that's just a way of seeming egalitarian and not really dealing with the issue. It feels bad to talk about shitty programmers but they're kind of a problem.
  - deleted 12y ago
    [deleted]
- angersock 12y ago
  Linus was right, though. On a project like that, you can't afford to let people slowly creep in lots of bullshit.
ibebrett 12y ago
all of his points except for one are related to the jvm in general, which most people agree doesn't suck, and then when it is time to address java he just says "scala, clojure.. are great" Yes, thats the point. The JVM is well liked, but Java as a language is not, and I don't think he did much to change anyones opinion.
- sklogic 12y ago
  I do not agree that JVM does not suck. It sucks badly. No tail calls support, no (optional and confined) unsafe pointer arithmetics, no value types and a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). edit: I suspect that none of the downvoters ever implemented a single compiler targeting JVM.
  - dlubarov 12y ago
    > No tail calls support Is there a good reason for VMs to support TCO rather than having compilers perform it? > no (optional and confined) unsafe pointer arithmetics When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. > no value types Might be added in JVMS 10 or some version thereafter. > a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. True. > All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). Fair enough, but it wasn't designed as a general purpose compilation target like llvm.
    - sklogic 12y ago
      > Is there a good reason for VMs to support TCO rather than having compilers perform it? Again this word! Proper tail calls handling is not an "optimisation". Optimisations are supposed to be optional, while tail calls handling makes a semantic difference. And, no, compilers cannot do it statically. You cannot statically resolve virtual calls, for example. Consider the following trivial case: `(define (f g x) (g x))` > When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. Try implementing, say, an STG efficiently. Or even a WAM. > Might be added in JVMS 10 or some version thereafter. JVM may start to suck less at some point. But now it sucks. > but it wasn't designed as a general purpose compilation target like llvm. Exactly. And that's why it's inferior to the other VMs, which were designed with multiple source language semantics in mind. Including even CLR.
api 12y ago
TL;DR: Java as a language is not bad. The problem with Java is its bloatware ecosystem. Endemic to the Java world are uninstallability, Rube Goldberg machine code, and such heights of over-engineering that they're easily parodied: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... I think the over-engineering is an unintended side effect of Java's most attractive features: incredibly stable standard ABIs, portable byte code, fantastic tooling, and a language that makes byzantine abstractions relatively easy to implement without the instability you get in C++ or the unmaintainability you get in dynamic languages. Sometimes you actually do need very high level complex abstractions, so this makes Java a fantastic language for those cases. But those cases are rare. Java makes it easy to build towers of babel that stand up, so they happen. Java can be fine if you exercise discipline around complexity. Java coders need YAGNI and KISS tattooed on their inner eyelids more than coders in other languages.
- justinsb 12y ago
  I think that is both fair and unfair. Fair because what you say is absolutely true. But unfair because if you stick to the non-bloatware libraries, Java is very good, very fast and surprisingly productive. For me, that stack is Guava, Jetty, Jersey, Gson, Guice. I believe though that you can make poor library choices in any language & framework. With languages that have been around for a while, there are a lot of bad libraries...
  - nogridbag 12y ago
    The last time I tried using a similar stack, I found out the latest Jersey doesn't play nicely with Guice, since jersey uses its own DI library (HK2). Only one user was actively trying to solve the problem and eventually I gave up and looked at alternatives like Ninja framework (which uses Guice, but not jersey).
    - justinsb 12y ago
      Ah, true. I still use Jersey 1. Jersey 2 has gone bloatware, sadly. We need a cleaner implementation of JAX-RS (which is really what we want, not Jersey per-se); I've worked on Apache Wink a little bit, but really Jersey 1 is good enough & good. I don't know what happened with JAX-RS 2. It feels like the J2EE team got hold of it... (PS Thanks for the Ninja suggestion; I will check it out)
serve_yay 12y ago
I agree with the article -- as it says, "The Java Language Kinda Sucks" :)
aligajani 12y ago
Who said Java sucks? The Java "language" is just too verbose for my liking, but the Java as a toolset is very powerful. Been using it for Big Data.
- jostmey 12y ago
  Agreed. It is awesome for what it is. But it is not my cup of tea.
- julienchastang 12y ago
  Agreed about the verbosity and Java 8 is only making the situation worse. I've been a Clojure enthusiast for a number of years now, but I was hoping there would be less of a need to use other JVM languages with Java 8 and Streams. I find working with Streams to be 3 steps forward and 2 back. The syntax (as usual) is cumbersome, and add a layer of generics on top of that and you have somewhat of a mess. I also find interop with traditional Java Collections to be annoying though maybe I am not following (yet to be discovered) best practices for dealing with Streams. Edit: Ohh and BTW, if you ever have the opportunity to see James Ward speak in person, do so. He is a great presenter, and a regular cast member at the Boulder Java User Group.
- Someone1234 12y ago
  This kind of sums up my opinion on the top (warning, is a little inflammatory): http://www.slideshare.net/jeffz/why-java-sucks-and-c-rocks-final http://www.slideshare.net/jeffz/why-java-sucks-and-c-rocks-f... I won't defend the tone of that but some of the points are valid (particularly with Java pre-8).
serve_yay 12y ago
It is only tangentially related, but I recommend this video from Brian Geotz, a Java language architect. He breaks down the challenges of adding features to the language, in a room full of Clojure devs no less. Worth a watch: https://www.youtube.com/watch?v=2y5Pv4yN0b0 https://www.youtube.com/watch?v=2y5Pv4yN0b0
WalterSear 12y ago
From the article: The Java Language Kinda Sucks
tacos 12y ago
It's hard to imagine someone who wouldn't be turned off by the tone of this article. Kicker is the quote at the end: "If you are in a typical enterprise then maybe you are lucky and already doing most of this." I went looking for sarcasm twice and still couldn't find it. Java enterprise shops are not using git and JRebel and Play Framework and continuous deployments and 2 week sprints and reactive development refactoring boilerplate into lambdas. Nor are they "mocking" amazon web services for ease of local developer testing. And a request to your boss to write the next services layer in "Kotlin" is likely to be met with the slap it deserves.
- VieElm 12y ago
  In which case find a new job. I don't understand why people stick with these hell holes for engineers when there are many opportunities to be found elsewhere. You can even find remote work so even if you're stuck in a small town with only one Java employer and you have a family and can't move you can still find that dream remote job with modern tooling and practices. If you apply to these remote jobs but aren't getting hired, that's a solvable problem too. Keep trying to learn more, self-improving and keep applying.
  - SomeCallMeTim 12y ago
    > Keep trying to learn more, self-improving and keep applying. I think it's worthwhile to add "improve your job application strategy" to that list. There was just an article on the how bad resumes are at predicting success; the converse is that you can likely improve your resume if you're not getting offers. And write a cover letter. Probably one in 20 (or maybe one in a hundred) resumes come in with a cover letter. And make it relevant. Talk about what the company does and how you'd be a good fit. Paraphrase their requirements list as a list of your strengths, and explain how things you don't know can be overcome. When I do this I have almost always gotten an interview. [1] And when I get an interview I almost always get an offer. [2] The other strategy that works for me is to network. Go to MeetUps relevant to your field and interact with people. I don't care if you're an introvert; I am too. It's hard. But do it. It's worth it. Right now I have a remote job that pays well where I was recommended by a friend who I met because I was networking. [1] The only exception for me was the months following 9/11, when no one was hiring because the whole nation was in shock. [2] I really recommend "Cracking the Coding Interview" by Gayle Laakmann McDowell; if you can answer all of the questions relevant to your field, you should be golden.
philsnow 12y ago
> It would have been much better to utilize environment variables so the only thing that changed between environments was those variables. I strongly prefer commandline arguments to environment variables: They're more transparent, easier to reason about ("what's running on this server? `ps`... oh, that process there is running in the staging configuration instead of production"), and it saves useless sudos (/proc/<pid>/environ has mod bits 0400, so if the processes you're investigating are running as separate users (and they probably should be), you can't inspect the actual environment that the process has, so you end up sudo'ing to check the environment out when you should have all the information you need in the process list). If the environment variables are just interpolated into the run script by the deploy and then all passed to the process as arguments, that works too.
- Someone1234 12y ago
  I strongly agree. Often times environmental variables are used inappropriately and make tracking down issues harder due to loss of transparency. Plus environmental variables are context specific (e.g. user 1 and user 2 might have different ones, or server 1 and server 2 might, or this specific script may have re-defined one(!)). A good o' fashioned script with the constants defined at the top, commented, and passed into executables on the command line (so tools like ps or taskman can "see" them) is really easy to debug/alter/monitor. Java and or Oracle's obsession with environmental variables causes more problems than it solves.
  - realusername 12y ago
    I also agree, the only way I would use environment variables is for global configuration like HTTP_PROXY for example, otherwise I still prefer arguments, at least there is no surprises.
    - philsnow 12y ago
      I was sad when I learned about this http_proxy environment variable and that things were actually starting to use it. An http proxy setting is no more suited for an environment variable than anything else. I think it should just be a string in a file in $XDG_CONFIG_DIR/http_proxy.conf or something like that.
devniel 12y ago
totally agree. What about testing EJBs?, it was painful for me, it took me many hours.
- mooreds 12y ago
  People still use EJBs? What, are we still listening to Gorillaz?
  - Havvy 12y ago
    I still listen to Gorillaz, but I don't use EJBs.
- poweribo 12y ago
  yeah EJBs are dead. check out dropwizard
jontro 12y ago
I'm not sure about the "Useless Blocking Sucks" paragraph, it's very opinionated and using the play framework in production is nothing I would recommend for enterprise deployments. The technology is still very immature and I do not see that the overhead of an extra thread per request would matter.
- tormeh 12y ago
  How is it immature? It is used in enterprises already, and they seem to like it.
halis 12y ago
SharePoint doesn't suck you're just using it wrong..
bkeroack 12y ago
The problem is not necessarily with Java or the JVM as a technology, but rather the "Java shop culture"[1] that often goes along with it. Although I would call it "Enterprise shop culture" instead, since it seems to stem from people who (sometimes unknowingly) perpetuate big company politics and a consultant attitude, even in startups. I've found "Java shop culture" in non-Java places as well--C#/.NET for example. 1. http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/ http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol...
- georgemcbay 12y ago
  Yup. Java as a runtime is a really nice piece of technology, Java as a language is pretty good, if a bit dry. It is the heavy-weight anti-YAGNI ecosystems that grow around it (the AbstractFactoryFactoryManager APIs that these Java shop cultures tend to produce) that makes working with Java suck, in my experience. And yes, that stuff can be avoided if you aren't stuck working on a maintenance project and you are really careful to smash down any signs of that sort of culture growing when you see it.
- peterashford 12y ago
  I've coded with Java for... well, since it came out (C, C++, Lisp before that) and I have never worked at any place with a culture like that. In fact, in my experience, it's the Microsoft shops that have been all (wannabe) Enterprisey (yes - that is a word)
javaistheworst 12y ago
No really, Java the language is bad. Terrible in fact. The fact I need an IDE to make it workable (just) highlights this point. J2EE was terrible too, because it showed where things can go, if you let the Java astronaut architects lead. Some of my most profitable projects were helping to rescue systems by migrating to to an alternative language on the JVM, or off it completely. The worst part is the damage Java inflicted upon a generation of developers. I have a problem, I think I will use Java, and Eclipse, and Maven, and all the rest. Now I have twenty thousand problems! Edit - if you disagree, then say so. Bit spineless to downvote without a valid point to back it up!
- nostromo 12y ago
  Speaking of spineless, did you really need a throwaway just to say Java sucks?
  - Scramblejams 12y ago
    As HN has grown it has attracted a more vocal contingent of Java developers. It's getting progressively harder to criticize the language without somebody shouting you down.
    - ww520 12y ago
      It seems the anti-Java ones are the more vocal ones most of the time. You see the anti-Java posts all the times.
      - Scramblejams 12y ago
        Those of us who are recovering Java programmers might say there's a good reason for that. :-)
        oldmanjay 12y ago
        That doesn't make you right, it just makes you noisy
lcfcjs 12y ago
Wow makes me dislike Java even more lol @jamesward
nickik 12y ago
>Clojure: The lack of some OO constructs makes managing a large code base challenging I would be intrested in what his problem is. The only thing that I can think of is subtyping and Im not sure how subtyping helps managing organisation. Clojures namespacing is pretty nice, it might be a bit to complicated but it does everything you need.
- escherize 12y ago
  And if you're just learning, sticking to the (ns hn.comment (:require [clojure.string :as str])) syntax is a good bet.
untog 12y ago
So first… Use a build tool. It doesn’t matter if you choose Ant + Ivy, Maven, Gradle, or sbt To me, that's part of the problem. The Java ecosystem seems diverse to a fault.
- jlward4th 12y ago
  Most platforms have pretty fragmented build tooling. I think an exception might be Go because it has the build tool built into the platform.
- sehugg 12y ago
  All of these tools can use (and sometimes create) Maven packages, which is pretty much the standard for library projects.
dschiptsov 12y ago
Why not, you have started it.) Before down-voting and replying, please, copy and paste examples from the Rosetta Code website, which would prove my statements to be incorrect. 1. Syntactic noise. 2. Verbosity. These gives us lots of cryptic lines of code, full of design patterns and other kluges. This is also related to the two below: 3. Over-abstraction. 4. Everything must be a member of a class. These two are simple and straightforward. These few pages long stack traces is a result of these unnecessary method calls. 5. Static typing makes our code safe. This nonsense results in even more lines of cryptic code ("generics") and even longer stack traces. I am not talking about XML configs, over-"engineered" components (beans, servlets, etc.) Here is a lemma: Any algorithm (at least those represented on the Rosetta Code website) could be coded with less lines of code, less words per line, less "special symbols" (with much better readability) and executed with less memory waste (this one excluding scripting languages for obvious reasons) in any other mainstream language. Period. Sure, Java does not suck. It is stupid us, who are unable to "get it".
- Crito 12y ago
  Not that I typically defend Java, but I think that (going by your Rosetta Code algorithm comparison test) Java fairs well against a few mainstream languages: Rosetta Code's Java Quicksort: http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Java http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Jav... Not great, that first line is a wreck in particular, but not terrible either. Compare that to this though: http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#C.2B.2B http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#C.2... Really quite ugly looking code. Now, this isn't entirely fair; one of C++'s faults/benefits is that depending on your shop and/or framework/libraries, "idiomatic" C++ can vary greatly. Template heavy C++ tends to look like vomit. C++ that uses Boost will typically be more unpleasant to look at than C++ that uses Qt (imho anyway). Java really comes into it's own horrible self when you get beyond mere algorithm implementation. A quicksort method in Java will tend to be relatively fine, but for projects larger than that it becomes idiomatic to make your java code a real mess.
  - cheepin 12y ago
    Quicksort looks significantly better in a functional style. Here's some Haskell, but it certainly doesn't use any Haskell-exclusive features: quicksort :: Ord a => [a] -> [a] quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter (< p) xs greater = filter (>= p) xs
dlwj 12y ago
Java itself was once so popular that a completely unrelated programming language, javascript, had java in its name to ride the coat-tails of its popularity. The culture and behaviors that have grown up around it though make it easy for people to fall into holes. (Both technical and non-technical, e.g. hiring culture) It's like if a minefield existed via the path of Java and people said "There's no way through this minefield." And another retorts "Of course there is a path! Just go through it carefully, learn the topology, and it's just as fast as sprinting across an open meadow."
- _lce0 12y ago
  Are you talking of java? It reads like PHP to me
talles 12y ago
Listed without no further text on the Clojure's bad parts: "Dynamic typing". That's very very debatable, don't you think mr. Ward?
- jlward4th 12y ago
  Definitely. Which is why I labelled that section as my opinions. :)
  - talles 12y ago
    Touche :) I guess I just felt bad to see all those great bulleted itens with some nice phrasing around and then to see my dear Dynamic Typing there, alone, without any adjective. No love, no hate, simply emotionless "Bad" :(
    - jlward4th 12y ago
      Good point. I should have put more details in there. I prefer static typing with good type inference because it allows me to have a compiler validate a lot of my code pre-runtime. Otherwise I'm left with tests and actually running all of the code to do that validation. The value of this for large code bases has been worth the tradeoffs in my experience. But since this is one of the most debated things in programming I don't expect to sway anyone. I'm happy to leave this as an item of "it depends" / personal preference.
  - weavejester 12y ago
    Clojure does have optional static typing via core.typed. It's still in active development, and the tooling around it is still rough around the edges, but it's a more sophisticated type system than Java's.
lostcolony 12y ago
I'm confused about the title of this. I've never heard an argument that went "Java sucks because you are forced to (thing on this list)". It's always been "Java sucks because it lacks (thing it certainly lacks)" or "Java sucks because it forces you to (thing it certainly forces you to do)", or, closest to this article, "Java sucks because it encourages you to (bad practice, such as those mentioned in this article)". None of these does the article refute. I've seen places that used Java, and had most of these, and places that used Java and had little of it. I've seen places that used other languages that had all of these, and other places that used those same other languages that had none of it. This seems kind of orthogonal, and as such a bit of a strawman; is it in response to some specific arguments I've just not heard?
debacle 12y ago
Java has some problems. I would contend that using the wrong tool for the job == using the tool wrong. Java has its place, but overall there is a better, more specialized solution in most instances that doesn't have some of Java's (pretty hideous) warts.
th3iedkid 12y ago
>>Spend a couple evenings or weekends working on implementing one of these items. Then show your manager what you did in your own time (that will convey how much you care) and then let them take the credit for the amazing new thing they thought of. Why would someone want to do that , unless its someone's personal project?
- jimbokun 12y ago
  If the expected cost of interviewing for and finding a new job where these things are already in place is greater than the cost of a couple evenings or weekends to add those features to the current work environment.
AhtiK 12y ago
"#1 Install the JDK" No developer should install JDK, it's a mess, madness and risk for crapware. Just use the JDK zip/tar.gz for that one specific project. Even for distributing java apps I find it much easier to bundle JRE with the app and never ask for the devop or end user install it separately. The license for bundling is quite permissive [1] and bundling can be also used for os x apps [2]. [1] http://www.oracle.com/technetwork/java/javase/jre-8-readme-2095710.html http://www.oracle.com/technetwork/java/javase/jre-8-readme-2... [2] https://docs.oracle.com/javase/jp/8/technotes/guides/jweb/packagingAppsForMac.html https://docs.oracle.com/javase/jp/8/technotes/guides/jweb/pa...
edpichler 12y ago
People, we are in 2014 and still discussing what programming language is better.
- Retra 12y ago
  2014 is not the future. It's not even a big number. The world we live in is actually quite primitive. That's why people who _care_ about things keep bringing them up.
  - edpichler 12y ago
    I believe languages war is not a good problem to spend energy.
    - Retra 12y ago
      Every worthwhile achievement in human history has been as a result of our mastery of language.
Sphax 12y ago
I maintain 2 semi-big Play 2 web services (written in Java, not Scala) at work, and I just hate it. - SBT is super slow compared to maven - Compiling a play 2 app is slow - IDE integration is quite bad After a year, I would definitely not recommend Play 2, or SBT on a Java project. My choice when using Java today would be Dropwizard, although I haven't deployed anything in production using it, I tested it for a couple hours, and I think it's the best combination of libraries. One thing I definitely agree on, is to use Docker if possible. We use it for almost everything at work, and it improves our deployment speed, it gives us more flexibility and local/CI testing is now super easy. In case you deploy with Docker, using only environment variables for configuration is great, that way you can control the configuration directly via the docker command line. With Java a good library for this use case is Typesafe's config, which can automatically use environment variables.
- danieldk 12y ago
  In the previous project I worked in, we switched to Dropwizard for a lot of services that now run in production. We were already using Jersey, Guava, etc., but Dropwizard gives some nice extra glue and standardized our configuration and gave us a standardized way to instrument services (via metrics). It can really recommend it for RESTful services. Also, there is a nice Maven plugin that creates Ubuntu packages from Dropwizard projects: https://github.com/reines/dropwizard-debpkg-maven-plugin https://github.com/reines/dropwizard-debpkg-maven-plugin
- jbooth 12y ago
  SBT is probably the best example of the total immaturity of the Scala community in terms of real-world engineering. Hey, we're building for the JVM, we've got Maven, it's arguably the best solution in any language for a very difficult problem that has stopped entire language ecosystems in their tracks. Let's rewrite it, from scratch, using unproven concepts! And put 'simple' in the title! Afterwards, we'll call XML ugly and claim to be more 'functional', without even noticing that Maven's pom format is actually a nested s-expression structure that happens to use angle brackets.
  - frowaway001 12y ago
kllrnohj 12y ago
> The blocking model limits parallelism, horizontal scalability, and the number of concurrent push connections. [citation needed] Seriously, where are the benchmarks? I see lots of claims of threads being slow and heavy (see also every time green threads comes up), yet... they are not. And every benchmark I've seen shows that, gasp, kernals are really fucking good. And library-of-the-week's greenthread kernel is not. The author then says you should use NIO. But, well, NIO is slower than blocking IO. A lot slower: http://www.mailinator.com/tymaPaulMultithreaded.pdf http://www.mailinator.com/tymaPaulMultithreaded.pdf So if you're using NIO instead of blocking IO threads, well, say goodbye to 25-30% of your throughput. But at least you got to feel all clever using unnecessarily complex async programming, so that's worth it, right?
- jlward4th 12y ago
  It definitely depends on what your needs are. There are tradeoffs on both sides.
  - crypto5 12y ago
    But for most of the typical web apps, non-blocking/reactive/etc programming is absolutely unnecessary.
- sehugg 12y ago
  Each thread has a minimum stack size which can grow memory quickly if you're using 10k's of threads. Using an async framework like Netty gets you into 100k connections and beyond. (Not that it's always the right thing to do unless you have lots of long-lived requests)
  - kllrnohj 12y ago
    Like all virtual memory the stack isn't actually allocated until it's used. So, no, that doesn't grow memory quickly. And while it's great Netty will get you to 100k connections, you can totally have 100k real threads on Linux. In fact, as far back as 2.5 in 2003 starting & stopping 100,000 concurrent threads took just 2 seconds with the introduction of NPTL. CPUs & memory have gotten a smidge faster since the Pentium 4 days so that time has almost certainly dropped significantly.
ohitsdom 12y ago
I'm a .NET developer and I love C# & Visual Studio but have worked some with Java. Most of his arguments sounded to me like- "Just do complex-sounding long list of steps, it's easy!" Java development seems like a massive pain, and too much time not actually spent on development.
- breischl 12y ago
  Maybe it's my similar background, but that's how I read it as well. My TL;DR summary of that article is "Java doesn't suck, as long as you use enough tools, libraries and workarounds to avoid actually using Java."
Dewie 12y ago
> If you need some ammunition to prove to your management that your startup times are killing your team’s productivity then use the stopwatch on your phone to count the total minutes per day wasted by waiting for the app to start. But... what about my sword-fighting
ausjke 12y ago
Suddenly I'm reading Java-come-back articles, which is nice. That convinced me to some extent I should learn Java more for serious coding, instead of spending the same time on php/python/javascript. Not saying the rest languages are bad, but life is too short to get good on all of them. Also Java is important for android.
- calebm 12y ago
  Satire?
deleted 12y ago
[deleted]
barrkel 12y ago
My company is doing most of these things (except it's more complex because we're polylingual, and don't use Java for web apps), but Java still sucks. The reason it sucks has more to do with the language and the culture that has grown up around it, than the mechanics of building and deploying that this article talks about. These mechanics have to be solved for most languages. They're table stakes; mostly just a basic level of usability from which you can start to measure against other things. If I had to name the single worst thing about Java, it would be the tendency for business code to degenerate into a 1:1:1 ratio of interface:class:public-method. For any significant piece of logic, it ends up living in a class on its own, with its dependencies injected either via constructor parameters or method parameters. Whether the constructor or method is used doesn't really matter, unless the method is to be called many times, in which case the constructor acts as a kind of partial application. And of course the class it lives in needs to be the only implementation of a corresponding interface, which only has a single method, the method in question. All other interesting methods this method calls must in turn be called via single-method interfaces, with these interfaces injected via parameters, one way or another. The cause of this is a religion around a particular style of testing. The development driven by the need to create tests for everything leads to code that has very little cohesion, very little structure, and most closely resembles 80s procedural code, but with vastly more ceremony. Code is hard to browse and read because the link between method call and implementation is hidden in a runtime indirection via an interface reference. This lack of legibility in turn encourages doing more work in these methods (albeit broken out into private methods), and instead of an OO decomposition of the problem, you end up with a poorly factored procedural decomposition. The biggest symptom is classes with names that are close anagrams of their primary method. For example: StaleJobsCleaner.cleanStaleJobs, StaleJobsFinder.findStaleJobs, JobDeleter.deleteJob, JobDepedencyFinder.findJobDependencies, etc.
- sbochins 12y ago
  This blog post helps explain why most Java projects end up with StaleJobsCleaner.cleanStaleJobs, etc. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- michaelochurch 12y ago
thehelix112 12y ago
Yes, it does.
mcguire 12y ago
"Decoupled Schema & Code Changes: When schema changes and code changes depend on each other rollbacks are really hard. Decoupling the two isolates risk and makes it possible to go back to a previous version of an app without having to also figure out what schema changes need to be made at the same time." I'd really like to know how you do that.
- the_fury 12y ago
  Generally you would use an expand/contract migration pattern. You deploy a schema expansion so that both the new and old code will run, deploy the new code, and once the new code has been validated you deploy a schema contraction. http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/ http://exortech.com/blog/2009/02/01/weekly-release-blog-11-z...
  - mcguire 12y ago
    That's what I came up with, too. But it's still coupled: you can't "go back to a previous version of an app without having to also figure out what schema changes need to be made", post-validation, anyway.
kazinator 12y ago
> Servers That Take More Than 30 Seconds to Start Suck > For developer productivity and so that scaling up can happen instantly, servers should startup quickly. Of course, a Java programmer takes it for granted that you restart things every time you change code. But that sucks. Servers should start up quickly. Well, what if they don't? What if they don't for some good reason?
- aries1980 12y ago
  It gives you extra costs and complexity on scalability and availability. Also makes continuous integration and frequent releases more tough than it should.
- Fishkins 12y ago
  > Of course, a Java programmer takes it for granted that you restart things every time you change code. But that sucks. Did you not read to the section about jRebel/Play and not needing to restart? But I do agree with you that server startup time isn't as big a deal if you don't have to restart after each change.
  - aries1980 12y ago
    These makes some debugging tricky because of the indirections the frameworks introduce and also comes with performance hit. A long start up time makes more difficult your integration/functional tests that it should.
    - neeme 12y ago
      JRebel IDE plugins integrate with your IDE debugger to hide the indirection from you. Works for me. If it does not work for you (or the performance hit is non-negligible) then I suggest you contact their support, they usually fix stuff in couple of days (from my personal experience). And, AFAIK, Play! is also fully debuggable. What's bothering you?
      - aries1980 12y ago
hit8run 12y ago
This article reads like an advertisement for play2. I created apps with play 1 and when play 2 was released I was quite excited hoping for things to get even better. Unfortunately the authors like Guillaume Bort and some others found love for Scala. Now the core framework is written in scala and play feels like a scala framework even though they added some Java Apis. The last time I checked play2 out there were conceptual inconsistencies between scala and java flavors of play2. For example Java comes with a hipster ORM (ebean) and Scala has a completely different almost non ORM flavor called anorm. Also IDE Support for play2 java flavor sucks. The biggest advantage of playframework was to have an agile framework like rails in the java world. This advantage has gone.
michaelvkpdx 12y ago
Java doesn't suck, not at all. I still find it to be the most productive language for developing systems big and small, mostly because it's well-understood, the pitfalls and traps are well-known, and the community is extensive and supportive, for the most part. Java got a bad rep because in the late 90's, enterprises hired anyone who had the word "Java" on their resume, with no real assessment of their actual proficiency in the language or programming skills. As a result, there was probably more bad code written in Java than any other language in history (including VB- you just can't write as much bad code in VB as you can in Java if you really (don't) know what you're doing). Much of this bad code ended up running flaky enterprise systems. So much bad code ended up in closed-source products (like Websphere, and like many JDBC drivers) that were sold to people who didn't really understand technology (but knew Java was sexy!) that Java itself got a bad name. No, the language isn't perfect. But with all the lessons learned, and with the great developments in Java since Oracle took over (I cannot believe I wrote and believe that now), I contend it's perhaps the single best language for general purpose software in 2014. The things James talks about in this article are all big problems that have less to do with the language than with the poor development practices that became so endemic to the community as a result of the rush to hire anyone with a pulse to be a Java programmer 15 years ago.
- javaistheworst 12y ago
  It would be cheap and easy to label this view as almost a perfect example of Stockholm syndrome, but I would suggest you may need to be a little more objective and critical of your tools. The master works with a variety of tools exactly because they have strengths and weaknesses. Java has some extreme weaknesses in verbosity, almost to the point of programming language diarrhea. It envelopes a development culture that gave us things like: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.
- hawleyal 12y ago
  List<String> list = new ArrayList<String>() Please make me type more redundant words.
  - 12y ago
jimmaswell 12y ago
One of the few big problems I have with Java is that you can't use anonymous classes as real closures like it intuitively looks like you should be able to.
sehrope 12y ago
> If your app needs a relational database then use an in-memory db like hsql or cloud services like Heroku Postgres, RDS, Redis Labs, etc. However one risk with most in-memory databases is that they differ from what is used in production. JPA / Hibernate try to hide this but sometimes bugs crop up due to subtle differences. So it is best to mimic the production services for developers even down to the version of the database. The idea that you can develop locally or test against a different type of database then what you are (or will be) using in production is silly. I don't just think it "sometimes" is a bad idea, I reject it outright. You should always be using the exact same database (type and version). For cloud deployments most XaaS providers have cheap or free dev tiers. For local development it's easy to use VMs. For any project that requires external resources (Postgres, Redis, RabbitMQ, etc) I have a VM that gets spun up via Vagrant[1]. Just "vagrant up" and all external resources required by the app should be available. > So first… Use a build tool. It doesn’t matter if you choose Ant + Ivy, Maven, Gradle, or sbt. Just pick one and use it to automatically pull your dependencies from Maven Central or your own Artifactory / Nexus server. With WebJars you can even manage your JavaScript and CSS library dependencies. Then get fancy by automatically denying SCM check-ins that include Jar files. Though I agree that it's a good idea to have dependencies externalized, it's not always possible. Some libraries (ex: third party JARs) are not available in public Maven repos and not everyone has a private one setup. In those situations it's fine to check in the JAR into the project itself. I like the approach outlined by Heroku for dealing with unmanaged dependencies[2]. You declare them normally in your pom.xml but also include the path to a local directory (checked into SCM) with the JAR files. Anybody that clones your repo should be able to build the project with no manual steps. Works great! [1]: https://www.vagrantup.com/ https://www.vagrantup.com/ [2]: https://devcenter.heroku.com/articles/local-maven-dependencies https://devcenter.heroku.com/articles/local-maven-dependenci...
kendallpark 12y ago
Because we needed an article to clear this up. :P
strangename 12y ago
His last note should have been his first; it's the Java environment that doesn't suck in any magnitude more than other environments, and has oodles of benefits for getting Serious Business done. You now have your choice of language with which you can enjoy the rock-steady JVM/JDK-library environment.
stealthlogic 12y ago
TL;DR: Java doesn't suck, you do.
vorg 12y ago
> Groovy > * Great > * * Simple language with a few very useful features Simple? Have you seen Codehaus Groovy's grammar?... http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/antlr/groovy.g http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/... That's from 2007 and more's been added since. What hasn't changed is it's still in Antlr 2 whereas the latest version of Antlr is version 4. Groovy's not simple, it's an obsolete dinosaur.
habosa 12y ago
I love Java. When used correctly it's a very powerful language that is easy to run in many environments. I choose it for any personal project that I can see growing beyond a few small scripts. I hate Java culture. Too much Enterprise Java is filled with SomeThingImpl, MyModelDAO, SomeShittyBean, and magical XML configurations. I don't know how things got this way (I haven't been around long enough) but there is no reason Java the language has to be attached to this nonsense. I totally understand why people take one look at a modern Java codebase and swear off the language forever. For me though, Java is the mainstream language that I find makes me most likely to be correct the first time I write a program. Yes that comes with verbosity. Yes that means I have to use a RAM-hungry IDE. But I write code that runs fast and correctly the first time. I love that. TL;DR - Java (The Language) != Java (The Culture)
- kyllo 12y ago
  Exactly. Java is fine if you just write plain-old classes. It's when you overuse patterns and try to make everything hyper pluggable/configurable with XML-based dependency injection that it becomes a disgusting slog. I write Java that is 100% "Plain Old Java Objects" and it is just fine. Keep it simple.
hysan 12y ago
If I'm reading this correctly, it just boils down to "use the right tools and Java won't suck" which is something that can be argued for most programming languages. This is fine and all, but one of the problems for new programmers (the majority of languages comparers) is that learning what Java toolset to use is a huge hurdle. Java's diverse ecosystem and long history hurt its image by making it seem like a hulking monstrosity that is reserved for enterprises. Combine this with the verbose syntax and any cursory glance at Java will drive most new programmers away. Compare this with other languages that do not suffer from such a poor image and it becomes easy to see why people often say, "Java sucks." What I wonder is if the following exists: * A simple/clean tutorial that introduces a developer to the most common tool chain (perhaps various tutorials for different use cases - web, desktop apps, gamedev, etc.). * Instructions that don't just name drop, as this article does, but instead gives concrete examples that lead to a fully functional work environment. Perhaps one that works as this author describes - scripts to setup dev environments, deployment, CI, etc. * Advanced instructions that point you to documentation in the case that you need to go beyond a simple work environment. * A comparison of various tools in the Java ecosystem that compares the use cases and, more importantly, gives examples of how various tools would be effectively used together. One of the reasons why I personally find Java to "suck" is because the friction involved in getting up and running in an efficient manner is far greater than that of other programming languages. I think that rather than write such an article defending Java, it would be much better to create a beginner resource that can onboard developers easily.
koffiezet 12y ago
I haven't used Java for a long time myself - and am not up to date with it's current featureset. I know I used to like coding in Java back in 2000/2001, but my professional career demanded switching to C/C++ - which I did and also said goodbye to a few years ago. Anyway - something I posted yesterday in the "Java for everything" thread here: > My view of Java may be a bit biased, since I also tend to look at things from the sysadmin pov nowadays. I can only tell that I never disliked Java until I had to take care of the monstrosities the Java developers bring to life, and mind you - I started out as a Java dev back in 2000. > > The main issue I have with Java is the JVM and memory usage and leaks. No matter what people claim - no memory leaks in Java is a fairy-tale. We run both custom C++ and Java services (about 50/50) on a few hundred servers - and I cannot find a single issue in our ticketing system related to memory problems with any of our C++ services. Java services? Every. Single. Week. When I get an alert some JBoss unexpectedly died or became unresponsive - "java.lang.OutOfMemoryError" is most likely going to be the problem. A lot of those are permgen space errors, and yes you can try all the "fixes" like increasing the permgenspace, permgensweeping, enabling class unloading, ... but these don't always fix the problem and slow down your services. Every time this happened in our own services, this had to be fixed by our developers. It takes weeks to locate the problem, and you end up deploying new versions, upgrading JBoss, JSF, Bouncycastle, ... whatever. After a while dealing with crap like this - you start avoiding projects using the JVM (although elasticsearch is pretty nice)

187 points by craigkerstiens 12y ago

As a side note, I can still remember how nice it felt to use Java in the mid-nineties coming from C++.

I think an important lesson for web application development—mentioned in the article—is keeping the server stateless, moving state into the client, and using a real middleware like Redis for the session cache.

shadeless 12y ago

Someone could argue that Java and PHP suck because there are a lot of people who use them wrongly. Linus Torvalds made a similar argument for not using C++: http://article.gmane.org/gmane.comp.version-control.git/57918/ http://article.gmane.org/gmane.comp.version-control.git/5791...

serve_yay 12y ago
I would agree with that, though perhaps more about PHP than Java. We like to say "use the right tool for the job" and "you can write bad code in any language", but that's just a way of seeming egalitarian and not really dealing with the issue. It feels bad to talk about shitty programmers but they're kind of a problem.
- deleted 12y ago
  [deleted]
angersock 12y ago
Linus was right, though. On a project like that, you can't afford to let people slowly creep in lots of bullshit.

ibebrett 12y ago

all of his points except for one are related to the jvm in general, which most people agree doesn't suck, and then when it is time to address java he just says "scala, clojure.. are great" Yes, thats the point. The JVM is well liked, but Java as a language is not, and I don't think he did much to change anyones opinion.

sklogic 12y ago
I do not agree that JVM does not suck. It sucks badly. No tail calls support, no (optional and confined) unsafe pointer arithmetics, no value types and a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). edit: I suspect that none of the downvoters ever implemented a single compiler targeting JVM.
- dlubarov 12y ago
  > No tail calls support Is there a good reason for VMs to support TCO rather than having compilers perform it? > no (optional and confined) unsafe pointer arithmetics When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. > no value types Might be added in JVMS 10 or some version thereafter. > a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. True. > All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). Fair enough, but it wasn't designed as a general purpose compilation target like llvm.
  - sklogic 12y ago
    > Is there a good reason for VMs to support TCO rather than having compilers perform it? Again this word! Proper tail calls handling is not an "optimisation". Optimisations are supposed to be optional, while tail calls handling makes a semantic difference. And, no, compilers cannot do it statically. You cannot statically resolve virtual calls, for example. Consider the following trivial case: `(define (f g x) (g x))` > When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. Try implementing, say, an STG efficiently. Or even a WAM. > Might be added in JVMS 10 or some version thereafter. JVM may start to suck less at some point. But now it sucks. > but it wasn't designed as a general purpose compilation target like llvm. Exactly. And that's why it's inferior to the other VMs, which were designed with multiple source language semantics in mind. Including even CLR.

api 12y ago

TL;DR: Java as a language is not bad. The problem with Java is its bloatware ecosystem. Endemic to the Java world are uninstallability, Rube Goldberg machine code, and such heights of over-engineering that they're easily parodied: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... I think the over-engineering is an unintended side effect of Java's most attractive features: incredibly stable standard ABIs, portable byte code, fantastic tooling, and a language that makes byzantine abstractions relatively easy to implement without the instability you get in C++ or the unmaintainability you get in dynamic languages. Sometimes you actually do need very high level complex abstractions, so this makes Java a fantastic language for those cases. But those cases are rare. Java makes it easy to build towers of babel that stand up, so they happen. Java can be fine if you exercise discipline around complexity. Java coders need YAGNI and KISS tattooed on their inner eyelids more than coders in other languages.

justinsb 12y ago
I think that is both fair and unfair. Fair because what you say is absolutely true. But unfair because if you stick to the non-bloatware libraries, Java is very good, very fast and surprisingly productive. For me, that stack is Guava, Jetty, Jersey, Gson, Guice. I believe though that you can make poor library choices in any language & framework. With languages that have been around for a while, there are a lot of bad libraries...
- nogridbag 12y ago
  The last time I tried using a similar stack, I found out the latest Jersey doesn't play nicely with Guice, since jersey uses its own DI library (HK2). Only one user was actively trying to solve the problem and eventually I gave up and looked at alternatives like Ninja framework (which uses Guice, but not jersey).
  - justinsb 12y ago
    Ah, true. I still use Jersey 1. Jersey 2 has gone bloatware, sadly. We need a cleaner implementation of JAX-RS (which is really what we want, not Jersey per-se); I've worked on Apache Wink a little bit, but really Jersey 1 is good enough & good. I don't know what happened with JAX-RS 2. It feels like the J2EE team got hold of it... (PS Thanks for the Ninja suggestion; I will check it out)

serve_yay 12y ago

I agree with the article -- as it says, "The Java Language Kinda Sucks" :)

aligajani 12y ago

Who said Java sucks? The Java "language" is just too verbose for my liking, but the Java as a toolset is very powerful. Been using it for Big Data.

jostmey 12y ago
Agreed. It is awesome for what it is. But it is not my cup of tea.
julienchastang 12y ago
Agreed about the verbosity and Java 8 is only making the situation worse. I've been a Clojure enthusiast for a number of years now, but I was hoping there would be less of a need to use other JVM languages with Java 8 and Streams. I find working with Streams to be 3 steps forward and 2 back. The syntax (as usual) is cumbersome, and add a layer of generics on top of that and you have somewhat of a mess. I also find interop with traditional Java Collections to be annoying though maybe I am not following (yet to be discovered) best practices for dealing with Streams. Edit: Ohh and BTW, if you ever have the opportunity to see James Ward speak in person, do so. He is a great presenter, and a regular cast member at the Boulder Java User Group.
Someone1234 12y ago
This kind of sums up my opinion on the top (warning, is a little inflammatory): http://www.slideshare.net/jeffz/why-java-sucks-and-c-rocks-final http://www.slideshare.net/jeffz/why-java-sucks-and-c-rocks-f... I won't defend the tone of that but some of the points are valid (particularly with Java pre-8).

serve_yay 12y ago

It is only tangentially related, but I recommend this video from Brian Geotz, a Java language architect. He breaks down the challenges of adding features to the language, in a room full of Clojure devs no less. Worth a watch: https://www.youtube.com/watch?v=2y5Pv4yN0b0 https://www.youtube.com/watch?v=2y5Pv4yN0b0

WalterSear 12y ago

From the article: The Java Language Kinda Sucks

tacos 12y ago

It's hard to imagine someone who wouldn't be turned off by the tone of this article. Kicker is the quote at the end: "If you are in a typical enterprise then maybe you are lucky and already doing most of this." I went looking for sarcasm twice and still couldn't find it. Java enterprise shops are not using git and JRebel and Play Framework and continuous deployments and 2 week sprints and reactive development refactoring boilerplate into lambdas. Nor are they "mocking" amazon web services for ease of local developer testing. And a request to your boss to write the next services layer in "Kotlin" is likely to be met with the slap it deserves.

VieElm 12y ago
In which case find a new job. I don't understand why people stick with these hell holes for engineers when there are many opportunities to be found elsewhere. You can even find remote work so even if you're stuck in a small town with only one Java employer and you have a family and can't move you can still find that dream remote job with modern tooling and practices. If you apply to these remote jobs but aren't getting hired, that's a solvable problem too. Keep trying to learn more, self-improving and keep applying.
- SomeCallMeTim 12y ago
  > Keep trying to learn more, self-improving and keep applying. I think it's worthwhile to add "improve your job application strategy" to that list. There was just an article on the how bad resumes are at predicting success; the converse is that you can likely improve your resume if you're not getting offers. And write a cover letter. Probably one in 20 (or maybe one in a hundred) resumes come in with a cover letter. And make it relevant. Talk about what the company does and how you'd be a good fit. Paraphrase their requirements list as a list of your strengths, and explain how things you don't know can be overcome. When I do this I have almost always gotten an interview. [1] And when I get an interview I almost always get an offer. [2] The other strategy that works for me is to network. Go to MeetUps relevant to your field and interact with people. I don't care if you're an introvert; I am too. It's hard. But do it. It's worth it. Right now I have a remote job that pays well where I was recommended by a friend who I met because I was networking. [1] The only exception for me was the months following 9/11, when no one was hiring because the whole nation was in shock. [2] I really recommend "Cracking the Coding Interview" by Gayle Laakmann McDowell; if you can answer all of the questions relevant to your field, you should be golden.

philsnow 12y ago

> It would have been much better to utilize environment variables so the only thing that changed between environments was those variables. I strongly prefer commandline arguments to environment variables: They're more transparent, easier to reason about ("what's running on this server? `ps`... oh, that process there is running in the staging configuration instead of production"), and it saves useless sudos (/proc/<pid>/environ has mod bits 0400, so if the processes you're investigating are running as separate users (and they probably should be), you can't inspect the actual environment that the process has, so you end up sudo'ing to check the environment out when you should have all the information you need in the process list). If the environment variables are just interpolated into the run script by the deploy and then all passed to the process as arguments, that works too.

Someone1234 12y ago
I strongly agree. Often times environmental variables are used inappropriately and make tracking down issues harder due to loss of transparency. Plus environmental variables are context specific (e.g. user 1 and user 2 might have different ones, or server 1 and server 2 might, or this specific script may have re-defined one(!)). A good o' fashioned script with the constants defined at the top, commented, and passed into executables on the command line (so tools like ps or taskman can "see" them) is really easy to debug/alter/monitor. Java and or Oracle's obsession with environmental variables causes more problems than it solves.
- realusername 12y ago
  I also agree, the only way I would use environment variables is for global configuration like HTTP_PROXY for example, otherwise I still prefer arguments, at least there is no surprises.
  - philsnow 12y ago
    I was sad when I learned about this http_proxy environment variable and that things were actually starting to use it. An http proxy setting is no more suited for an environment variable than anything else. I think it should just be a string in a file in $XDG_CONFIG_DIR/http_proxy.conf or something like that.

devniel 12y ago

totally agree. What about testing EJBs?, it was painful for me, it took me many hours.

mooreds 12y ago
People still use EJBs? What, are we still listening to Gorillaz?
- Havvy 12y ago
  I still listen to Gorillaz, but I don't use EJBs.
poweribo 12y ago
yeah EJBs are dead. check out dropwizard

jontro 12y ago

I'm not sure about the "Useless Blocking Sucks" paragraph, it's very opinionated and using the play framework in production is nothing I would recommend for enterprise deployments. The technology is still very immature and I do not see that the overhead of an extra thread per request would matter.

tormeh 12y ago
How is it immature? It is used in enterprises already, and they seem to like it.

halis 12y ago

SharePoint doesn't suck you're just using it wrong..

bkeroack 12y ago

The problem is not necessarily with Java or the JVM as a technology, but rather the "Java shop culture"[1] that often goes along with it. Although I would call it "Enterprise shop culture" instead, since it seems to stem from people who (sometimes unknowingly) perpetuate big company politics and a consultant attitude, even in startups. I've found "Java shop culture" in non-Java places as well--C#/.NET for example. 1. http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/ http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol...

georgemcbay 12y ago
Yup. Java as a runtime is a really nice piece of technology, Java as a language is pretty good, if a bit dry. It is the heavy-weight anti-YAGNI ecosystems that grow around it (the AbstractFactoryFactoryManager APIs that these Java shop cultures tend to produce) that makes working with Java suck, in my experience. And yes, that stuff can be avoided if you aren't stuck working on a maintenance project and you are really careful to smash down any signs of that sort of culture growing when you see it.
peterashford 12y ago
I've coded with Java for... well, since it came out (C, C++, Lisp before that) and I have never worked at any place with a culture like that. In fact, in my experience, it's the Microsoft shops that have been all (wannabe) Enterprisey (yes - that is a word)

javaistheworst 12y ago

No really, Java the language is bad. Terrible in fact. The fact I need an IDE to make it workable (just) highlights this point. J2EE was terrible too, because it showed where things can go, if you let the Java astronaut architects lead. Some of my most profitable projects were helping to rescue systems by migrating to to an alternative language on the JVM, or off it completely. The worst part is the damage Java inflicted upon a generation of developers. I have a problem, I think I will use Java, and Eclipse, and Maven, and all the rest. Now I have twenty thousand problems! Edit - if you disagree, then say so. Bit spineless to downvote without a valid point to back it up!

nostromo 12y ago
Speaking of spineless, did you really need a throwaway just to say Java sucks?
- Scramblejams 12y ago
  As HN has grown it has attracted a more vocal contingent of Java developers. It's getting progressively harder to criticize the language without somebody shouting you down.
  - ww520 12y ago
    It seems the anti-Java ones are the more vocal ones most of the time. You see the anti-Java posts all the times.
    - Scramblejams 12y ago
      Those of us who are recovering Java programmers might say there's a good reason for that. :-)
      - oldmanjay 12y ago
        That doesn't make you right, it just makes you noisy

lcfcjs 12y ago

Wow makes me dislike Java even more lol @jamesward

nickik 12y ago

>Clojure: The lack of some OO constructs makes managing a large code base challenging I would be intrested in what his problem is. The only thing that I can think of is subtyping and Im not sure how subtyping helps managing organisation. Clojures namespacing is pretty nice, it might be a bit to complicated but it does everything you need.

escherize 12y ago
And if you're just learning, sticking to the (ns hn.comment (:require [clojure.string :as str])) syntax is a good bet.

untog 12y ago

So first… Use a build tool. It doesn’t matter if you choose Ant + Ivy, Maven, Gradle, or sbt To me, that's part of the problem. The Java ecosystem seems diverse to a fault.

jlward4th 12y ago
Most platforms have pretty fragmented build tooling. I think an exception might be Go because it has the build tool built into the platform.
sehugg 12y ago
All of these tools can use (and sometimes create) Maven packages, which is pretty much the standard for library projects.

dschiptsov 12y ago

Why not, you have started it.) Before down-voting and replying, please, copy and paste examples from the Rosetta Code website, which would prove my statements to be incorrect. 1. Syntactic noise. 2. Verbosity. These gives us lots of cryptic lines of code, full of design patterns and other kluges. This is also related to the two below: 3. Over-abstraction. 4. Everything must be a member of a class. These two are simple and straightforward. These few pages long stack traces is a result of these unnecessary method calls. 5. Static typing makes our code safe. This nonsense results in even more lines of cryptic code ("generics") and even longer stack traces. I am not talking about XML configs, over-"engineered" components (beans, servlets, etc.) Here is a lemma: Any algorithm (at least those represented on the Rosetta Code website) could be coded with less lines of code, less words per line, less "special symbols" (with much better readability) and executed with less memory waste (this one excluding scripting languages for obvious reasons) in any other mainstream language. Period. Sure, Java does not suck. It is stupid us, who are unable to "get it".

Crito 12y ago
Not that I typically defend Java, but I think that (going by your Rosetta Code algorithm comparison test) Java fairs well against a few mainstream languages: Rosetta Code's Java Quicksort: http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Java http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Jav... Not great, that first line is a wreck in particular, but not terrible either. Compare that to this though: http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#C.2B.2B http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#C.2... Really quite ugly looking code. Now, this isn't entirely fair; one of C++'s faults/benefits is that depending on your shop and/or framework/libraries, "idiomatic" C++ can vary greatly. Template heavy C++ tends to look like vomit. C++ that uses Boost will typically be more unpleasant to look at than C++ that uses Qt (imho anyway). Java really comes into it's own horrible self when you get beyond mere algorithm implementation. A quicksort method in Java will tend to be relatively fine, but for projects larger than that it becomes idiomatic to make your java code a real mess.
- cheepin 12y ago
  Quicksort looks significantly better in a functional style. Here's some Haskell, but it certainly doesn't use any Haskell-exclusive features: quicksort :: Ord a => [a] -> [a] quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter (< p) xs greater = filter (>= p) xs

dlwj 12y ago

Java itself was once so popular that a completely unrelated programming language, javascript, had java in its name to ride the coat-tails of its popularity. The culture and behaviors that have grown up around it though make it easy for people to fall into holes. (Both technical and non-technical, e.g. hiring culture) It's like if a minefield existed via the path of Java and people said "There's no way through this minefield." And another retorts "Of course there is a path! Just go through it carefully, learn the topology, and it's just as fast as sprinting across an open meadow."

_lce0 12y ago
Are you talking of java? It reads like PHP to me

talles 12y ago

Listed without no further text on the Clojure's bad parts: "Dynamic typing". That's very very debatable, don't you think mr. Ward?

jlward4th 12y ago
Definitely. Which is why I labelled that section as my opinions. :)
- talles 12y ago
  Touche :) I guess I just felt bad to see all those great bulleted itens with some nice phrasing around and then to see my dear Dynamic Typing there, alone, without any adjective. No love, no hate, simply emotionless "Bad" :(
  - jlward4th 12y ago
    Good point. I should have put more details in there. I prefer static typing with good type inference because it allows me to have a compiler validate a lot of my code pre-runtime. Otherwise I'm left with tests and actually running all of the code to do that validation. The value of this for large code bases has been worth the tradeoffs in my experience. But since this is one of the most debated things in programming I don't expect to sway anyone. I'm happy to leave this as an item of "it depends" / personal preference.
- weavejester 12y ago
  Clojure does have optional static typing via core.typed. It's still in active development, and the tooling around it is still rough around the edges, but it's a more sophisticated type system than Java's.

lostcolony 12y ago

I'm confused about the title of this. I've never heard an argument that went "Java sucks because you are forced to (thing on this list)". It's always been "Java sucks because it lacks (thing it certainly lacks)" or "Java sucks because it forces you to (thing it certainly forces you to do)", or, closest to this article, "Java sucks because it encourages you to (bad practice, such as those mentioned in this article)". None of these does the article refute. I've seen places that used Java, and had most of these, and places that used Java and had little of it. I've seen places that used other languages that had all of these, and other places that used those same other languages that had none of it. This seems kind of orthogonal, and as such a bit of a strawman; is it in response to some specific arguments I've just not heard?

debacle 12y ago

Java has some problems. I would contend that using the wrong tool for the job == using the tool wrong. Java has its place, but overall there is a better, more specialized solution in most instances that doesn't have some of Java's (pretty hideous) warts.

th3iedkid 12y ago

>>Spend a couple evenings or weekends working on implementing one of these items. Then show your manager what you did in your own time (that will convey how much you care) and then let them take the credit for the amazing new thing they thought of. Why would someone want to do that , unless its someone's personal project?

jimbokun 12y ago
If the expected cost of interviewing for and finding a new job where these things are already in place is greater than the cost of a couple evenings or weekends to add those features to the current work environment.

AhtiK 12y ago

"#1 Install the JDK" No developer should install JDK, it's a mess, madness and risk for crapware. Just use the JDK zip/tar.gz for that one specific project. Even for distributing java apps I find it much easier to bundle JRE with the app and never ask for the devop or end user install it separately. The license for bundling is quite permissive [1] and bundling can be also used for os x apps [2]. [1] http://www.oracle.com/technetwork/java/javase/jre-8-readme-2095710.html http://www.oracle.com/technetwork/java/javase/jre-8-readme-2... [2] https://docs.oracle.com/javase/jp/8/technotes/guides/jweb/packagingAppsForMac.html https://docs.oracle.com/javase/jp/8/technotes/guides/jweb/pa...

edpichler 12y ago

People, we are in 2014 and still discussing what programming language is better.

Retra 12y ago
2014 is not the future. It's not even a big number. The world we live in is actually quite primitive. That's why people who _care_ about things keep bringing them up.
- edpichler 12y ago
  I believe languages war is not a good problem to spend energy.
  - Retra 12y ago
    Every worthwhile achievement in human history has been as a result of our mastery of language.

Sphax 12y ago

I maintain 2 semi-big Play 2 web services (written in Java, not Scala) at work, and I just hate it. - SBT is super slow compared to maven - Compiling a play 2 app is slow - IDE integration is quite bad After a year, I would definitely not recommend Play 2, or SBT on a Java project. My choice when using Java today would be Dropwizard, although I haven't deployed anything in production using it, I tested it for a couple hours, and I think it's the best combination of libraries. One thing I definitely agree on, is to use Docker if possible. We use it for almost everything at work, and it improves our deployment speed, it gives us more flexibility and local/CI testing is now super easy. In case you deploy with Docker, using only environment variables for configuration is great, that way you can control the configuration directly via the docker command line. With Java a good library for this use case is Typesafe's config, which can automatically use environment variables.

danieldk 12y ago
In the previous project I worked in, we switched to Dropwizard for a lot of services that now run in production. We were already using Jersey, Guava, etc., but Dropwizard gives some nice extra glue and standardized our configuration and gave us a standardized way to instrument services (via metrics). It can really recommend it for RESTful services. Also, there is a nice Maven plugin that creates Ubuntu packages from Dropwizard projects: https://github.com/reines/dropwizard-debpkg-maven-plugin https://github.com/reines/dropwizard-debpkg-maven-plugin
jbooth 12y ago
SBT is probably the best example of the total immaturity of the Scala community in terms of real-world engineering. Hey, we're building for the JVM, we've got Maven, it's arguably the best solution in any language for a very difficult problem that has stopped entire language ecosystems in their tracks. Let's rewrite it, from scratch, using unproven concepts! And put 'simple' in the title! Afterwards, we'll call XML ugly and claim to be more 'functional', without even noticing that Maven's pom format is actually a nested s-expression structure that happens to use angle brackets.
- frowaway001 12y ago

kllrnohj 12y ago

> The blocking model limits parallelism, horizontal scalability, and the number of concurrent push connections. [citation needed] Seriously, where are the benchmarks? I see lots of claims of threads being slow and heavy (see also every time green threads comes up), yet... they are not. And every benchmark I've seen shows that, gasp, kernals are really fucking good. And library-of-the-week's greenthread kernel is not. The author then says you should use NIO. But, well, NIO is slower than blocking IO. A lot slower: http://www.mailinator.com/tymaPaulMultithreaded.pdf http://www.mailinator.com/tymaPaulMultithreaded.pdf So if you're using NIO instead of blocking IO threads, well, say goodbye to 25-30% of your throughput. But at least you got to feel all clever using unnecessarily complex async programming, so that's worth it, right?

jlward4th 12y ago
It definitely depends on what your needs are. There are tradeoffs on both sides.
- crypto5 12y ago
  But for most of the typical web apps, non-blocking/reactive/etc programming is absolutely unnecessary.
sehugg 12y ago
Each thread has a minimum stack size which can grow memory quickly if you're using 10k's of threads. Using an async framework like Netty gets you into 100k connections and beyond. (Not that it's always the right thing to do unless you have lots of long-lived requests)
- kllrnohj 12y ago
  Like all virtual memory the stack isn't actually allocated until it's used. So, no, that doesn't grow memory quickly. And while it's great Netty will get you to 100k connections, you can totally have 100k real threads on Linux. In fact, as far back as 2.5 in 2003 starting & stopping 100,000 concurrent threads took just 2 seconds with the introduction of NPTL. CPUs & memory have gotten a smidge faster since the Pentium 4 days so that time has almost certainly dropped significantly.

ohitsdom 12y ago

I'm a .NET developer and I love C# & Visual Studio but have worked some with Java. Most of his arguments sounded to me like- "Just do complex-sounding long list of steps, it's easy!" Java development seems like a massive pain, and too much time not actually spent on development.

breischl 12y ago
Maybe it's my similar background, but that's how I read it as well. My TL;DR summary of that article is "Java doesn't suck, as long as you use enough tools, libraries and workarounds to avoid actually using Java."

Dewie 12y ago

> If you need some ammunition to prove to your management that your startup times are killing your team’s productivity then use the stopwatch on your phone to count the total minutes per day wasted by waiting for the app to start. But... what about my sword-fighting

ausjke 12y ago

Suddenly I'm reading Java-come-back articles, which is nice. That convinced me to some extent I should learn Java more for serious coding, instead of spending the same time on php/python/javascript. Not saying the rest languages are bad, but life is too short to get good on all of them. Also Java is important for android.

calebm 12y ago
Satire?

deleted 12y ago

[deleted]

barrkel 12y ago

My company is doing most of these things (except it's more complex because we're polylingual, and don't use Java for web apps), but Java still sucks. The reason it sucks has more to do with the language and the culture that has grown up around it, than the mechanics of building and deploying that this article talks about. These mechanics have to be solved for most languages. They're table stakes; mostly just a basic level of usability from which you can start to measure against other things. If I had to name the single worst thing about Java, it would be the tendency for business code to degenerate into a 1:1:1 ratio of interface:class:public-method. For any significant piece of logic, it ends up living in a class on its own, with its dependencies injected either via constructor parameters or method parameters. Whether the constructor or method is used doesn't really matter, unless the method is to be called many times, in which case the constructor acts as a kind of partial application. And of course the class it lives in needs to be the only implementation of a corresponding interface, which only has a single method, the method in question. All other interesting methods this method calls must in turn be called via single-method interfaces, with these interfaces injected via parameters, one way or another. The cause of this is a religion around a particular style of testing. The development driven by the need to create tests for everything leads to code that has very little cohesion, very little structure, and most closely resembles 80s procedural code, but with vastly more ceremony. Code is hard to browse and read because the link between method call and implementation is hidden in a runtime indirection via an interface reference. This lack of legibility in turn encourages doing more work in these methods (albeit broken out into private methods), and instead of an OO decomposition of the problem, you end up with a poorly factored procedural decomposition. The biggest symptom is classes with names that are close anagrams of their primary method. For example: StaleJobsCleaner.cleanStaleJobs, StaleJobsFinder.findStaleJobs, JobDeleter.deleteJob, JobDepedencyFinder.findJobDependencies, etc.

sbochins 12y ago
This blog post helps explain why most Java projects end up with StaleJobsCleaner.cleanStaleJobs, etc. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
michaelochurch 12y ago

thehelix112 12y ago

Yes, it does.

mcguire 12y ago

"Decoupled Schema & Code Changes: When schema changes and code changes depend on each other rollbacks are really hard. Decoupling the two isolates risk and makes it possible to go back to a previous version of an app without having to also figure out what schema changes need to be made at the same time." I'd really like to know how you do that.

the_fury 12y ago
Generally you would use an expand/contract migration pattern. You deploy a schema expansion so that both the new and old code will run, deploy the new code, and once the new code has been validated you deploy a schema contraction. http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/ http://exortech.com/blog/2009/02/01/weekly-release-blog-11-z...
- mcguire 12y ago
  That's what I came up with, too. But it's still coupled: you can't "go back to a previous version of an app without having to also figure out what schema changes need to be made", post-validation, anyway.

kazinator 12y ago

> Servers That Take More Than 30 Seconds to Start Suck > For developer productivity and so that scaling up can happen instantly, servers should startup quickly. Of course, a Java programmer takes it for granted that you restart things every time you change code. But that sucks. Servers should start up quickly. Well, what if they don't? What if they don't for some good reason?

aries1980 12y ago
It gives you extra costs and complexity on scalability and availability. Also makes continuous integration and frequent releases more tough than it should.
Fishkins 12y ago
> Of course, a Java programmer takes it for granted that you restart things every time you change code. But that sucks. Did you not read to the section about jRebel/Play and not needing to restart? But I do agree with you that server startup time isn't as big a deal if you don't have to restart after each change.
- aries1980 12y ago
  These makes some debugging tricky because of the indirections the frameworks introduce and also comes with performance hit. A long start up time makes more difficult your integration/functional tests that it should.
  - neeme 12y ago
    JRebel IDE plugins integrate with your IDE debugger to hide the indirection from you. Works for me. If it does not work for you (or the performance hit is non-negligible) then I suggest you contact their support, they usually fix stuff in couple of days (from my personal experience). And, AFAIK, Play! is also fully debuggable. What's bothering you?
    - aries1980 12y ago

hit8run 12y ago

This article reads like an advertisement for play2. I created apps with play 1 and when play 2 was released I was quite excited hoping for things to get even better. Unfortunately the authors like Guillaume Bort and some others found love for Scala. Now the core framework is written in scala and play feels like a scala framework even though they added some Java Apis. The last time I checked play2 out there were conceptual inconsistencies between scala and java flavors of play2. For example Java comes with a hipster ORM (ebean) and Scala has a completely different almost non ORM flavor called anorm. Also IDE Support for play2 java flavor sucks. The biggest advantage of playframework was to have an agile framework like rails in the java world. This advantage has gone.

michaelvkpdx 12y ago

Java doesn't suck, not at all. I still find it to be the most productive language for developing systems big and small, mostly because it's well-understood, the pitfalls and traps are well-known, and the community is extensive and supportive, for the most part. Java got a bad rep because in the late 90's, enterprises hired anyone who had the word "Java" on their resume, with no real assessment of their actual proficiency in the language or programming skills. As a result, there was probably more bad code written in Java than any other language in history (including VB- you just can't write as much bad code in VB as you can in Java if you really (don't) know what you're doing). Much of this bad code ended up running flaky enterprise systems. So much bad code ended up in closed-source products (like Websphere, and like many JDBC drivers) that were sold to people who didn't really understand technology (but knew Java was sexy!) that Java itself got a bad name. No, the language isn't perfect. But with all the lessons learned, and with the great developments in Java since Oracle took over (I cannot believe I wrote and believe that now), I contend it's perhaps the single best language for general purpose software in 2014. The things James talks about in this article are all big problems that have less to do with the language than with the poor development practices that became so endemic to the community as a result of the rush to hire anyone with a pulse to be a Java programmer 15 years ago.

javaistheworst 12y ago
It would be cheap and easy to label this view as almost a perfect example of Stockholm syndrome, but I would suggest you may need to be a little more objective and critical of your tools. The master works with a variety of tools exactly because they have strengths and weaknesses. Java has some extreme weaknesses in verbosity, almost to the point of programming language diarrhea. It envelopes a development culture that gave us things like: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.
hawleyal 12y ago
List<String> list = new ArrayList<String>() Please make me type more redundant words.
- 12y ago

jimmaswell 12y ago

One of the few big problems I have with Java is that you can't use anonymous classes as real closures like it intuitively looks like you should be able to.

sehrope 12y ago

> If your app needs a relational database then use an in-memory db like hsql or cloud services like Heroku Postgres, RDS, Redis Labs, etc. However one risk with most in-memory databases is that they differ from what is used in production. JPA / Hibernate try to hide this but sometimes bugs crop up due to subtle differences. So it is best to mimic the production services for developers even down to the version of the database. The idea that you can develop locally or test against a different type of database then what you are (or will be) using in production is silly. I don't just think it "sometimes" is a bad idea, I reject it outright. You should always be using the exact same database (type and version). For cloud deployments most XaaS providers have cheap or free dev tiers. For local development it's easy to use VMs. For any project that requires external resources (Postgres, Redis, RabbitMQ, etc) I have a VM that gets spun up via Vagrant[1]. Just "vagrant up" and all external resources required by the app should be available. > So first… Use a build tool. It doesn’t matter if you choose Ant + Ivy, Maven, Gradle, or sbt. Just pick one and use it to automatically pull your dependencies from Maven Central or your own Artifactory / Nexus server. With WebJars you can even manage your JavaScript and CSS library dependencies. Then get fancy by automatically denying SCM check-ins that include Jar files. Though I agree that it's a good idea to have dependencies externalized, it's not always possible. Some libraries (ex: third party JARs) are not available in public Maven repos and not everyone has a private one setup. In those situations it's fine to check in the JAR into the project itself. I like the approach outlined by Heroku for dealing with unmanaged dependencies[2]. You declare them normally in your pom.xml but also include the path to a local directory (checked into SCM) with the JAR files. Anybody that clones your repo should be able to build the project with no manual steps. Works great! [1]: https://www.vagrantup.com/ https://www.vagrantup.com/ [2]: https://devcenter.heroku.com/articles/local-maven-dependencies https://devcenter.heroku.com/articles/local-maven-dependenci...

kendallpark 12y ago

Because we needed an article to clear this up. :P

strangename 12y ago

His last note should have been his first; it's the Java environment that doesn't suck in any magnitude more than other environments, and has oodles of benefits for getting Serious Business done. You now have your choice of language with which you can enjoy the rock-steady JVM/JDK-library environment.

stealthlogic 12y ago

TL;DR: Java doesn't suck, you do.

vorg 12y ago

> Groovy > * Great > * * Simple language with a few very useful features Simple? Have you seen Codehaus Groovy's grammar?... http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/antlr/groovy.g http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/... That's from 2007 and more's been added since. What hasn't changed is it's still in Antlr 2 whereas the latest version of Antlr is version 4. Groovy's not simple, it's an obsolete dinosaur.

habosa 12y ago

I love Java. When used correctly it's a very powerful language that is easy to run in many environments. I choose it for any personal project that I can see growing beyond a few small scripts. I hate Java culture. Too much Enterprise Java is filled with SomeThingImpl, MyModelDAO, SomeShittyBean, and magical XML configurations. I don't know how things got this way (I haven't been around long enough) but there is no reason Java the language has to be attached to this nonsense. I totally understand why people take one look at a modern Java codebase and swear off the language forever. For me though, Java is the mainstream language that I find makes me most likely to be correct the first time I write a program. Yes that comes with verbosity. Yes that means I have to use a RAM-hungry IDE. But I write code that runs fast and correctly the first time. I love that. TL;DR - Java (The Language) != Java (The Culture)

kyllo 12y ago
Exactly. Java is fine if you just write plain-old classes. It's when you overuse patterns and try to make everything hyper pluggable/configurable with XML-based dependency injection that it becomes a disgusting slog. I write Java that is 100% "Plain Old Java Objects" and it is just fine. Keep it simple.

hysan 12y ago

If I'm reading this correctly, it just boils down to "use the right tools and Java won't suck" which is something that can be argued for most programming languages. This is fine and all, but one of the problems for new programmers (the majority of languages comparers) is that learning what Java toolset to use is a huge hurdle. Java's diverse ecosystem and long history hurt its image by making it seem like a hulking monstrosity that is reserved for enterprises. Combine this with the verbose syntax and any cursory glance at Java will drive most new programmers away. Compare this with other languages that do not suffer from such a poor image and it becomes easy to see why people often say, "Java sucks." What I wonder is if the following exists: * A simple/clean tutorial that introduces a developer to the most common tool chain (perhaps various tutorials for different use cases - web, desktop apps, gamedev, etc.). * Instructions that don't just name drop, as this article does, but instead gives concrete examples that lead to a fully functional work environment. Perhaps one that works as this author describes - scripts to setup dev environments, deployment, CI, etc. * Advanced instructions that point you to documentation in the case that you need to go beyond a simple work environment. * A comparison of various tools in the Java ecosystem that compares the use cases and, more importantly, gives examples of how various tools would be effectively used together. One of the reasons why I personally find Java to "suck" is because the friction involved in getting up and running in an efficient manner is far greater than that of other programming languages. I think that rather than write such an article defending Java, it would be much better to create a beginner resource that can onboard developers easily.

koffiezet 12y ago

I haven't used Java for a long time myself - and am not up to date with it's current featureset. I know I used to like coding in Java back in 2000/2001, but my professional career demanded switching to C/C++ - which I did and also said goodbye to a few years ago. Anyway - something I posted yesterday in the "Java for everything" thread here: > My view of Java may be a bit biased, since I also tend to look at things from the sysadmin pov nowadays. I can only tell that I never disliked Java until I had to take care of the monstrosities the Java developers bring to life, and mind you - I started out as a Java dev back in 2000. > > The main issue I have with Java is the JVM and memory usage and leaks. No matter what people claim - no memory leaks in Java is a fairy-tale. We run both custom C++ and Java services (about 50/50) on a few hundred servers - and I cannot find a single issue in our ticketing system related to memory problems with any of our C++ services. Java services? Every. Single. Week. When I get an alert some JBoss unexpectedly died or became unresponsive - "java.lang.OutOfMemoryError" is most likely going to be the problem. A lot of those are permgen space errors, and yes you can try all the "fixes" like increasing the permgenspace, permgensweeping, enabling class unloading, ... but these don't always fix the problem and slow down your services. Every time this happened in our own services, this had to be fixed by our developers. It takes weeks to locate the problem, and you end up deploying new versions, upgrading JBoss, JSF, Bouncycastle, ... whatever. After a while dealing with crap like this - you start avoiding projects using the JVM (although elasticsearch is pretty nice)