6 ms·

Why I love everything you hate about Java

• wooster 17y ago
  That's Scala, not Java. And this doesn't even begin to cover everything I dislike about Java.
  • bjclark 17y ago
    Fine sir, I believe you have missed the point.
    • slpsys 17y ago
      Disagree. There's 'boilerplate' introduced by the framework/pattern, which may be necessitated when you throw out default assumptions to scale (which I, wooster, the OP, and yourself probably all agree are not so cumbersome after all). Then there's boilerplate introduced by the language. That's where wooster diverges, and I agree.
• Tichy 17y ago
  Um, I don't hate Factories, Dependency Injection and Decorators. I hate that Java makes it very cumbersome to use them, typically via xml configuration files (so that it can be dynamic) and adding complex syntax (generics, annotations). And I hate that I can not pass functions as parameters. As he says in the article: "function composition is a degenerate case of the Decorator pattern." (not sure why "degenerate") - so instead of just composing functions, in Java I have to write countless classes and interfaces. That's what I hate.
  • jbooth 17y ago
    That's not Java. That's EJB. Or JPA. Or JBOSS. Or RMI. Or any other bad idea that's come out in the last 15 years. Java's been out and big for 15 years -- every bad idea has had a big push for it in Java. But the language? Something like a dozen keywords. With some really nice libraries like java.util.concurrent and the Collections API. Just because lousy designs have been written in Java doesn't mean it's a lousy language. It may be starting to get a little dated, but that's a different matter. It's basically becoming the C of the JVM at this point, with higher level languages like JRuby and Clojure to run in application space and Java as your platform space.
    • Tichy 17y ago
      Not quite - to be able to use factories and dependency injection, you have to use interfaces. And not being able to use functions as parameters (or write them on the fly) is annoying in all kinds of software development, not just enterprise software. Also, all the nice libraries have been updated to use the new language features like generics and annotations.
      • jbooth 17y ago
        You don't have to use interfaces in order to do dependency injection, you just probably should, depending on the task. I wrote something last week which injected dependencies directly to a class. Interfaces are actually one of the best ideas in Java, IMO, if you're using them appropriately. Generics and annotations are pretty useful. What's the matter with them? Have you spent time developing with them? They're certainly better than having to cast all over the place. RE: functions as parameters.. yeah that's kinda annoying. You can always do new Runnable() { void run() { doSomeStuff; }} but that's ridiculous. So you have a point there. Aside from that though, the language is suitable for most tasks, and requiring a little extra syntax when you want to pass functions around isn't the end of the world. Anyways, I'm sure I'm arguing against the trendy masses here, and I have a clojure book too, just trying to set up the opportunity to use it for something real.. but there's a reason why most "real" back-end stuff that has to be performant, stable and reliable winds up getting written in Java these days. That includes Hadoop, Lucene and half of the NoSQL key-value stores that you're excited about :)
        • nostrademons 17y ago
          A lot of the "real" performant/stable/reliable backends seem to be written in Scala and Erlang these days. People use whatever languages are production-ready state-of-the-art at the time they begin their systems. C++ was state-of-the-art when Google started in 1995; Java was state-of-the-art when Lucene/Hadoop started in the early 2000s; now people are building things in Scala and Erlang. Anyway, be careful when using "big and accepted" projects to indicate ideal platforms. It takes 5-10 years for a project to become big and accepted. In the process, its technology platform has probably become obsolete, but continues on because of inertia. Your goal should be to shoot for what your role models would do now, with the benefit of 10 years of additional technical development, and not where they were 10 years ago.
  • viraptor 17y ago
    I do hate Factories and DI. They are just buzzwords really. As someone mentioned in other comment - all those things he lists can be done in a dynamic language and some of them will be much easier. Factories == constructors meet partial application and functions passing. They seem to be objects only because Java lacks nice support for bare functions... DI / IoC == ... well ... good design. You're simply limiting the amount of state and coupling. Decorators, proxies, etc. - duck-typing and metaclasses are a bit more flexible here. And the first example is just passing a function to a threadpool - there's nothing very tricky about it either... It seems to me that author never used a dynamic language properly :(
    • sedachv 17y ago
      The problem dependency injection attempts to solve disappears when you have dynamic scoping. I've said this before - DI is probably the dumbest fad (no small feat) in object-oriented programming.
      • Tichy 17y ago
        Could you remind me what dynamic scoping is? Thanks!
        • viraptor 17y ago
          f() { return x; } g() { x=1; return f(); } f() returns x it inherits from g(). A spectacular way to shoot yourself in the foot.
          • Tichy 17y ago
            That looks like no scoping at all? I think JavaScript is a bit like that? But most languages would prevent that kind of thing?
            • regularfry 17y ago
              It's not no scoping - it's specifically scoped to where the call to f() was made, rather than where it was defined. It basically makes everything in scope in g() available to f() as a hidden parameter. Pre-CL Lisps had this by default. defvar is, as far as I can tell (still learning!) how you get at it now.
  • axod 17y ago
    What the hell has XML got to do with Java? You're confusing frameworks with languages. Most Java frameworks suck. Agreed.
    • Tichy 17y ago
      No, it is not a coincidence that Java and XML go hand in hand. Heavy XML usage was introduced into common Java practice to compensate for the lack of dynamic features in Java. So dynamic features were introduced (badly) through the XML backdoor. Also often XML is used as a poor mans DSL. It could have been something similar to XML (like JSON or YAML), but that is not the point. Also, the verbosity of XML aligns itself well with the Java mindset.
      • axod 17y ago
        Utter BS. I've been doing Java programming for 10 years and have never touched XML thank god. "the Java mindset" - more utter BS. There isn't a 'Java mindset' unless you're a bad programmer who is ruled by his language instead of using languages as tools. The "mindset" you have depends on how good a coder you are. Which is the same regardless of which language you decide to use to solve a particular problem.
        • Tichy 17y ago
          Fine, then you are the exception to the rule. As for the mindset, it seems to me that at least SUN was very busy churning out cookbooks for a lot of things. Mostly Enterprise Java - if you managed to avoid that, more power to you. But I think most people tried to do things the "official" way.
          • axod 17y ago
            Totally @ Enterprise. Horrible horrible stuff that, but really, there's some great technology in the JVM, and built in libs. And the Java language is a pretty sane general purpose language. It's fairly easy to spot all the crap and avoid it.
    • 17y ago
• deleted 17y ago
  [deleted]
• emmett 17y ago
  Quoth the author: In a very dynamic language like Ruby, open classes and method aliasing (e.g., alias_method_chain) mitigate this problem, but they don’t solve it. If you manipulate a class to add logging, all instances of that class will have logging; you can’t take a surgical approach and say “just objects instantiated in this context”. This is not true in Ruby! myinstance = MyClass.new def myinstance.special_method() puts "only on these instances!" end myinstance.special_method() The author's point about avoiding unnecessary binding is well taken, but he should refrain from declaiming on languages he doesn't know that well.
  • nkallen 17y ago
    Since you don't control the code that manufactures instances of MyClass.new, you don't have an opportunity to manipulate the metaclass/singleton class of instances of MyClass. So this technique doesn't work.
    • mr_eel 17y ago
      The basic idea is adding methods to single instances. It _does_ work. What you're talking about is sugar. You could easily create a factory which manipulates instances as they are created.
      • nkallen 17y ago
        Yes but you still need to inject the Factory. My point is not that Java is better than Ruby but that this style, which is commonly associated with Java, is better in any language.
        • nostrademons 17y ago
          Parameterizing behavior is usually a good thing in any language, yes... The part that Python/Ruby got right is that their culture says don't parameterize until you have to. While Java culture tends to build in generality for the sake of generality, whether or not the actual system needs it. Many systems don't, but if you use typical Java libraries, you need to pay the costs for it regardless. There was a red-flag in one of your comments above: "since you don't control the code, this technique doesn't work". If you don't control the code enough to make necessary modifications, you have a cultural problem, not a technical problem. Fix the culture, not the code. You should be building the simplest system that possibly works, not hacking around code ownership restrictions. Parameterization is useful when you have one piece of code that you know needs to work in multiple contexts, not when you're trying to make sure a piece of code will work in all possible contexts a priori.
• panic 17y ago
  This article has nothing to do with Java. You can write modular code in any decent language. In fact, I would argue that the author's approach would work better in a more dynamic language.
• deleted 17y ago
  [deleted]
• orangecat 17y ago
  Java especially in its enterprisey form is reasonably good at covering the maximum number of possible use cases, but it's bad at making the common cases simple. Yes, I should be able to write the one-line Future without boilerplate to get reasonable default behavior, and then add custom configuration later if I actually need it. That both reduces the amount of code and makes nonstandard usage more prominent.
  • jrockway 17y ago
    Yes, this is exactly what Java doesn't get. Reading a file with only the standard libraries is 5 lines of code. Hello world is 6. The main problem is that this encourages cargo-culting. Once someone has something working, they will just cut-n-paste-n-modify it in similar situations. Better to cargo-cult 10 lines of code than to write 5 of your own, right? The moving parts won't cut off your fingers as long as your fingers don't get too close. (Normally I would rant about how "proper abstraction is not possible with Java", but it actually is. It just seems that the majority of libraries and programmers would rather cargo-cult than to design proper abstractions. And no, "proper abstraction" is not always "cut-n-paste from GoF".)
    • TeHCrAzY 17y ago
      This is why I love .Net. Want a quick and dirty file read? string fileContent = System.IO.File.ReadAllText(); Want to read it into lines? string[] fileLines = System.IO.File.ReadAllLines(); Want fine tuned byte by byte access? var fs = new System.IO.FileStream(path); They certainly looked long and hard at Java before writing .net, and covered many of the sore points carefully.
      • cubicle67 17y ago
        I think you've missed specifying the filename, but otherwise cool. Here's Ruby for comparison: file_content = IO.read(filename) file_lines = IO.read(filename).split("\n")
        • deleted 17y ago
• theashworld 17y ago
  I think folks who complain about java must make sure that they are using a very powerful ide first (example: eclipse or intellij idea) If, having used and mastered a good ide and all it's features, you still don't like it, it's a fair point. Eclipse can make so many things in java drastically fast and easy. And I think that's where java shines. I'm yet to see as powerful an IDE for any other language. (Although I admit, I do not program for msft platforms and hence, never used msft ides)
  • brandon 17y ago
    I personally think the necessity of using an IDE merits complaint itself. Yes, Eclipse and IntelliJ do some pretty amazing things. I wish I had a toolset that nice for C/Python/whatever. By contrast, without the toolset in Java, you're sunk. Then again, I wouldn't imagine or expect some types of development to be achievable without a rich toolset (FPGA work comes to mind). I just like to think of Java as a more general purpose language.
    • prodigal_erik 17y ago
      This. I work on Java in Eclipse every day; it actually won me over from years of Emacs. But heavy-duty code navigation tools just manage the pain of bad abstraction, they're no substitute for a DRY language in which the work remains clear and concise enough that you can just sit down and read it.
    • axod 17y ago
      I think that's a misconception. FWIW I hate IDE's, and the code produced by people using them gives Java a bad name for its verbosity and idiocy. >> without the toolset in Java, you're sunk. No, you're not. Try it. Use an editor, write some code. It's not rocket science.
  • jrockway 17y ago
    Here's a Java IDE question: why doesn't Eclipse have a REPL in the default install? That's the one thing I use most in other languages. It's nice to be able to right click to rename things (although a perl oneliner works just as well in practice), but it's nicer to be able to know that your mini-algorithm works before you design a class around it. Why is the focus on "rename" and "extract method" instead of "write code that actually works"?
• grandalf 17y ago
  It's interesting to consider that Ruby blocks are essentially function composition with an anonymous function.
• johnwatson11218 17y ago
  I was a little confused by the fact that the post lists Scala as one of the "hipster" languages in the opening paragraph and then starts using it as an example of the java way? Just a slip?
  • plinkplonk 17y ago
    "I was a little confused by the fact that the post lists scala as one of the "hipster" languages in the opening paragraph and then starts using it as an example of the java way? " Well once you define the "java way" to be "build highly configurable code by providing a way to combine small granular pieces of code into larger chunks of functionality" (which is just Programming 101 , See SICP for e.g) it probably still makes sense to write the "java way" programs in Scala ;-) Makes sense to me! :-P As nostrademons says elsewhere on this thread ,"Parameterizing behavior is usually a good thing in any language, yes..."
• deleted 17y ago
  [deleted]
• jorsh 17y ago
  "If you’re one of those hipster programmers who loves Clojure, Ruby, Scala, Erlang, or whatever, you probably deeply loathe Java and all of its giant configuration files and bloated APIs of AbstractFactoryFactoryInterfaces." Can we just get a moratorium on usage of "hipster" now? Everybody's using it wrong.
• ighost 17y ago
  Writing Java apologetics with using Scala sounded like a great idea at first...
• cageface 17y ago
  Abstraction is essential in building complex systems but it comes at a price. Every layer increases the overall complexity of the code base and increases the cost of maintaining and extending it. Ideally languages and tools would allow you to begin with concrete & explicit code and gradually introduce increasing layers of abstraction as necessary. The problem I have with most Java frameworks is that they assume you're going to need a lot more abstraction than you likely need, so just getting an idea off the ground takes a lot of extra work. It's really just worse is better all over again. The reason things like Ruby and Rails are so popular is that they let you toss together something that "works" so much faster. It's a lot easier to rewrite a good first-mover app than it is to try to hoist all that Java baggage into a new problem space you don't understand. Come to think of it, isn't this exactly what Twitter did? If Twitter had been written as the article suggests would it have ever taken off?