14 ms·

Java Developers

256 points by nsainsbury 12y ago

pdrummond 12y ago
Good read - the bit about Android is spot on.
MrBuddyCasino 12y ago
Java hits a sweet spot of simplicity, platform stability, safety and performance. Also, its popularity in the enterprise is partly because interchangeable, cog-in-the-machine low quality developers can be productive in it and not cause too many meltdowns. Thats an economic advantage! If you need lots of cheap developers for your IT department, good luck finding 15 Clojure and Haskell gurus. I say that as a Java developer, btw.
- ayrx 12y ago
  Isn't it just a little sad that the biggest selling point of a language is that mediocre developers won't cause too many problems with it?
  - adamors 12y ago
    It's not sad, because most developers are mediocre. It may not apply to you, but if you work in the industry long enough you realize that very few of your colleagues are good/great. And there's nothing wrong with that, but if you want to build systems that have to be maintained over multiple years, you somehow have to compensate for that. Java is one compensation.
    - MrBuddyCasino 12y ago
      Exactly. By definition, most developers are mediocre, and thats okay. Platform stability and limiting complexity is really important in the long run, so (luckily, imho) C++ and Scala are non-starters.
      - Dewie 12y ago
        > Exactly. By definition, most developers are mediocre, and thats okay. That doesn't say much. So yes, most developers are average, but what is average? Is it necessarily developers who need training wheels, helmets and elbow pads in order to protect themselves and others? That may be the reality, for all I know. But that isn't necessarily a timeless truth. Take a room of expert programmers; now most of them are mediocre (average), relative to each other (imagine a really big room with a lot of experts, if you must). But that doesn't necessarily mean that they need languages that cramp their style in order to mitigate whatever damage they might do. "Mediocre" is the same as "average", but with more negative connotations. Hence, when someone says that some people are 'mediocre', the immediate thought might be "bad". Then it becomes obvious that tools need to hinder these bad developers from screwing up too much. But mediocre is just a relative term, and can mean that they are really bad developers who create 100 bugs for every feature they implement, or that they are really competent, reliable developers. I won't comment on the skill of the average (mediocre) developer. But I think that saying "most are mediocre" can easily hint at "most are bad" (because of connotations, not necessarily because that was the intent).
        MrBuddyCasino 12y ago
        True, there is a negative connotation there - maybe using that term was a mistake. There certainly are huge variations in baseline skill depending on location and line of business. I was thinking of the more or less generic enterprise software environment in firms whose main business is not software development, and which reside outside silicon valley or other tech hubs.
- dozzie 12y ago
  Simplicity -- none, if talking about the resulting code. Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Performance -- poor, regarding memory consumption. Indeed, the sweet spot. > If you need lots of cheap developers [...] Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent. It's the same hard finding decent Java programmers as it is with Haskell, except that Java scares good devs away and Haskell attracts them.
  - dtech 12y ago
    > Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Do you have actual examples of companies using Java for their run-of-the mill software that have been hit with lawsuits from Sun/Oracle? The only two I can remember are Sun vs Microsoft (because of proprietary extentions) and Oracle vs Google (complex licensing issues). Sounds like FUD to me.
  - matthewmacleod 12y ago
    Simplicity -- none, if talking about the resulting code. Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot. Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Bollocks. I challenge you to provide an example of a Java developer being sued for using the language. Performance -- poor, regarding memory consumption. Bollocks. Uses more memory than C, but no manual management. Sweet spot. Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent. Bollocks. In my experience, they're likely to be somewhat better skilled and educated. They're also far more likely to spend their time arse-ing around trying to implement an elegant, concise solution to problems which only exist because of not-invented-here syndrome, or because their language lacks as extensive a standard library. As an example, I once worked on a Mac GUI app for a company - bog-standard, nothing fancy. I took over from a developer who had been trying to build this using Racket; this involved building a Qt-Racket interface, which involved magical automated parsing of C++ header files, which meant… basically, not delivering a product. Meanwhile, the Objective C build was done. The point is, there's far too much focus and snobbery about what tools developers use. There are loads of languages out there; pick one that has a reasonable amount of support and fits the problem domain, and build simple, maintainable code. You can do that in any language.
Hermel 12y ago
There is a lot of Cargo Cult programming going on among Java developers. Why using a simple constructor when you can use the factory design pattern? Or why directly instantiating a logger using the "new" statement and the right arguments, when you can also configure it using xml files? Making use of design patterns and frameworks is professional, after all, isn't?
- dozzie 12y ago
  Actually, configuring logger with values stored in a separate file instead of hardcoded ones is a good thing. Logging configuration is configuration, after all. You wouldn't want paths to documents be hardcoded in your office suite, would you? Or target address of VPN gateway in VPN client?
- malka 12y ago
  over the years, I developped a fiery hatred of XML configuration files.
  - kasey_junk 12y ago
    and I'm starting to develop a fiery hatred for JSON configuration files. At least XML had standard support for schemas and querying.
  - virmundi 12y ago
    Over the years I've developed a deep understanding for why XML configuration is great. Java's move to annotation, upon annotation. As a result there is no single, canonical place I can go to see what the general configuration is. I have to track through classes, that may or may not have a good structure to find a specific instance of a route. Spring 3.x configurations, with inheritance are wonderful. The only work is to follow the imports.
- DCKing 12y ago
  Your statement sounds like a reverse cargo cult. The problem is not that people use these constructs that you mention. The problem is that people use the wrong constructs at the wrong time, don't seem particularly good at judging which to use when and just use the most convoluted one by default. There are many contexts in which the factory pattern is the best choice (although not the majority) and in which configuring logging externally is the best choice (almost always).
lukabratos 12y ago
Knock, knock. Who's there? Long pause ... Java!
TeeWEE 12y ago
While I do agree that java developers are often low quality developers. And than java frameworks are often bloated with Dependency Injection, Factories, Proxies etc... I disagree that Android has the same problems. To me it looks like Android was actually written in lean-and-mean java. Ok its still Object Oriented. But for UIX interfaces, Object Orientation makes a lot of sense... There are some areas in the android API that are indeed a bit bloated. And that is indeed inherent to java.
- boobsbr 12y ago
  > While I do agree that java developers are often low quality developers. That can be said for ANY language.
nick_riviera 12y ago
I disagree with this, as a part time Java developer (I do C# most of the time). The points I disagree with: 1. OO is bad. Every paradigm is bad if you misuse it. If you build deep abstractions then you will hang yourself regardless. Some very elegant and simple designs can emerge from OO code, but only if you think about the problems first. The majority of pain consists of forgetting to do that step. There is no magic bullet - FP has its own pitfalls as well as does simple procedural programming. 2. Everything looks like it's written by an architect. Well that's a broad generalisation and I'm sure some people titled architect would be sick at the association (considering they usually reduce complexity) but the problem here is that people aren't using the frameworks properly. Not joking but the last two or three Java web applications I've put together have virtually no code in them. It's just the domain model, the views and query encapsulations. Nothing else. The abstract factory factory factory factory crap isn't your problem. If you make it your problem, then you're just doing it wrong or not using the tools provided efficiently. 3. Android. Android is abysmal (I've written a couple of things for it so far), but that's not because of Java but the fact that the Android API and versioning mess is a pile of unstable crap. It'd be nice if there were't so many exceptions. If you're going to pick on Java, at least jump on: Idiotic code on the web, Glassfish being a right pile, view technology being foul, servlet container reloading, Swing/JavaFX or Eclipse...
- signal11 12y ago
  Some of the complaints about the over-formal language is a matter of taste, perhaps, but it does grate and is not a new complaint (see also: the Kingdom of Nouns rant). However Java developers are learning (or migrating to Scala/Groovy/Clojure). And there is hope -- the Play framework, for example, is an example of Java done right (imho). Spring 4 is moving in the right direction.
  - nick_riviera 12y ago
    I don't think it's a matter of taste. TBH I write very little of the code that is checked in to the source control. The IDE does all the boilerplate. I literally design the method signatures, define the access policy for the methods and fill in a few gaps here and there. Play is not Java done right by any means. It's tightly coupled, has really poor documentation, breaking changes galore between major releases, deployment is trouble (compared to tomcat) and rather tied to Scala's API. Java done right is picking some lego bricks that you stick together to get what you want and telling it how to wire them up. YYMV but 99.9% of all problems are already solved off the shelf.
skrebbel 12y ago
A lot of these bloated patterns that got popular in the Java world have shorter, simpler alternatives when programming in a functional style. You often don't need multiple child classes to implement a template method if you can just pass a function to the constructor. You don't need a BananaFactory if you can just inject a createBanana function. Remarkably many Gang of Four design patterns are unneeded once you can pass functions around. The C# world is now learning this: when C# 1 and 2 were popular, the ecosystem went right after Java in the kinds of boilerplate that the author describes. Now, many years of Func and Action goodness later, there's a large part of the community that codes way more to the point, and this part is growing. People who release C# libraries in 2014 with factories adapters and multiple layer inheritance hierarchies are laughed at. Since Java 8, Java too has an accessible way to pass functions around. Not really functions, because Java, but in practice it works the same way. This means that there's nothing technologically that's holding the Java community from making these improvements, too. I hope it happens.
- icebraining 12y ago
  I don't think Android supports Java 8, though.
  - Alphasite_ 12y ago
    I thought there was some work to support Lambdas in ART?
    - on_and_off 12y ago
      There is a retro-lambda library that allows to write lambda expressions. It is compiled to jdk 6 compatible bytecode though.
  - needusername 12y ago
    I don't think Android supports even Java 7. Sure, maybe source level but AFAIK invokedynamic and method handles are still missing.
  - mike_hearn 12y ago
markokrajnc 12y ago
Disclosure: Long time Java programmer here (since 1996, previously worked many years with Smalltalk). Java Language and Java Virtual Machine are great, but Java Libraries are in many cases too complicated (using too much of "Gang of Four" patterns).
seanmcdirmid 12y ago
> The OO craze has a part to play in this madness as well. More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit. Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do. > Even today you’ll still find a strong bias towards OO courses being taught at the university level using Java, and the bias was certainly stronger 5 - 10 years ago. Because that's what people use to write real programs. > The engineers at Google working on Android are too busy architecting grand frameworks for solutions and not busy enough solving actual problems. Because we all know, Google is known for hiring flakes who can't code or design real systems. Worse is better means getting things done even if your tools kind of suck or your understanding of the problem isn't yet great. It leads to architecting and less than ideal solutions, but at least you ship!
- DCKing 12y ago
  There seems to be an implication in your comment that people aren't using FP to write "big serious programs". Is that really what you are implying?
  - seanmcdirmid 12y ago
    In that domain, yes! How many UI frameworks are functional (beyond I think...Om?)?
    - agumonkey 12y ago
      Let's wait and see if Om inspire others. You know that ideas take time to diffuse, OOP/MVC has been a somehow natural fit for IHM, but like many other ideas (closures?) now that people can see it, maybe they'll change their mind.
    - DCKing 12y ago
      It's unfair to focus on "UI frameworks" when UI frameworks are specifically aimed at supporting client OSes where they have to deal with "preferred frameworks", all of which were developed when OO was all the craze. Functional programming has only been discovered as a practical paradigm quite recently! Besides, implying that "big serious programs" necessarily implies that they are UI programs is completely wrong. Unsurpisingly, if a given JS UI framework is OO, it is not OO in the traditional sense because JavaScript itself is not OO in the traditional sense. If you make a framework, you use the language of whatever runtime you are targeting. Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those services have less baggage of trends than UI heavy programs do. So you are arguing that there is some perceived evidence for OO in UI programming, but I think that could more easily be attributed to historical trends. Note that I'm not necessarily disagreeing with your conclusion, just that your reasoning is flawed.
_pmf_ 12y ago
The proliferation of factories is not an indication of over-architecting something. It is a direct consequence of finding a balance between maintainability and the lack of first class functions (or constructors as first class functions). If you have never had the need to introduce factories, I claim that you have not worked with a truly polymorphic system.
mobiuscog 12y ago
I agree with much of the article (also as being a java developer for the last 17 years). However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem: Frameworks. Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is at an all time high), and often code following 'best practices' handed down from academia/conferences/books that promote large abstractions which are often un-necessary. It's similar to how C code would end up having pointers-to-pointers-to-pointers-to-pointers... A whole generation (generalising/stereotyping, I know) is now coding, who have never grown up and learnt with basic logic gates and low-level code. The framework is the obvious choice because 'why would you want to write it yourself, if it exists' ? (Ironically, many Javascript developers seem to be intent on re-inventing everything that's gone before, and it's somehow seen as innovation - go figure) Grumpy old man ? Sure, I am. I'm also gladdened to see a recent upsurge in assembly language and other low-level coding, as this is what the world actually needs - less super-business-entrepreneurial startups, and more people able to actually solve real problems and not just hipster entertainment.
- UK-AL 12y ago
  Assembly, and Low Level Coding is the exact opposite of solving 'real' problems. Your going low level to create problems that didn't exist, as opposed to working on the core issue(often business related) your software is trying to solve. Languages should allow you to focus on creating software that fixes a real world problem, as fast and cleanly as you can. That doesn't include bit flipping, or bit operators or anything like that unless required. People should be working in super high-level languages like Haskell, OCaml, F#, Clojure, or languages that fit their domain perfectly. The goal is to fix problem the as concisely and quickly as possible.
  - dbaupp 12y ago
    Writing low-level code is important for writing the underlying libraries for those high-level languages, e.g. the run-time systems or the big integer routines.
therealmarv 12y ago
Java can be really glad that there is Google with Android. Otherwise this language would be a strong enterprise focused language with very bad reputation on the end user side.
- andybak 12y ago
  However - how many developers are turned off of being Android devs by the fact they have to use Java? (and I know that probably many more are attracted because they already know Java but that's not my point)
  - watwut 12y ago
    I was turned off by a.) horribly slow speed of Android virtual machine b.) being hard to code for it with maven c.) I did not particularly liked their xml language for gui. I would have to write mobile, I would use one of those languages that compile into both Android and iOS as much as possible.
    - cerberusss 12y ago
      Exactly. I personally think Java is fine. It's just that the development environment is much less nice than Xcode.
thescrewdriver 12y ago
I've been using Java for about 15 years and largely agree with the article. The verbosity of the Java language is definitely part of the problem, although that aspect is downplayed in his blog post. I agree with the author about the culture. Java programmers in general seem to be on some sort of design pattern frenzy, especially in the better known frameworks. It doesn't matter if you're writing a fancy framework or writing a trivial app to process a file, chances are you're going to see layer upon layer of over-engineering. I switched to Scala a couple of years back and have never been happier. Only part of the improvement is due to the language the other part is not having to deal with Spring, builder patterns, and madness like AbstractSingletonProxyFactoryBean [1]. My impression has been that the typical Scala developer has had lots of Java exposure and has learned from their experiences. [1] http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...
__Joker 12y ago
Can't agree more. The problem is not the language itself, rather who uses and whats the culture associated with it. Java is mostly used in the enterprises, where unfortunately thest "architects" exists. Architects are nothing but people have grown out of the roles and in a way of organization recognizing the peoples talent. Most of the times the Architects are redundant. Most of the cases use of Java is nothing but writing your business logic into the Java code. Unfortunately, architect to justify himself would try to engineer a solution, which never needed engineering itself. and down you go in the rabbit-hole of oops and abstraction. Unfortunately it will be pretty hard for Java to shake up this image.
- threeseed 12y ago
  Good architects play a vital role in the organisation especially if you have a sprawling set of agile teams that don't necessarily work together. There are plenty of really tough integration, security, scalability and performance challenges that need someone who is across the entire stack from very top to very bottom. You rarely find developers who can manage it all and still find time to cut code.
jackhiggs 12y ago
The real problem is developers not understanding Object Oriented programming. Many developers write procedural style in Java or any other OO language. So you get God classes, methods that are hundreds or thousands of lines long etc - I'm sure we've all seen those horror shows. It's just a lack of education coupled with a culture where there is no strive for technical excellence. You need high quality developers in Java, just as you do in any other language. It seems like the article's beef is with OO programming, not Java per se.
vijucat 12y ago
Blame the 90s : the Gang of Four design patterns book, UML, et al. If you wrote code that did not abstract enough, such as not using factories, it was jaw-droppingly obvious to your colleagues that you were not good enough. FP and Scala owe the sheer verbosity of Java a lot for their current success :-)
- pjmlp 12y ago
  Targeted at C++ and Smalltalk developers.
- tormeh 12y ago
  God. UML.
- cam- 12y ago
  Java has been round long enough to have been influenced by whatever was the coding fashion of the time. You can see it in the core java libraries and the supporting frameworks. OO and GoF where probably the biggest fashions and you can document when a core library was written by the approach to it.
moretti 12y ago
I think this code truly represents the essence of this article: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
jimmcslim 12y ago
Great article, but I especially encourage you to read the one before it as well... http://nsainsbury.svbtle.com/leonardo-da-vinci http://nsainsbury.svbtle.com/leonardo-da-vinci
mlangdon 12y ago
I for one appreciate the hard work that was Android and Java. I spent two years intensively self-teaching, primarily on Android before starting my developer job. Having to take in large, unwieldy systems with lots of moving parts was mind expanding. I could spend a night in the API, go to bed and wake up feeling smarter. I haven't done any Android for my job (and just a little Java), but every time I have to design more than a self-contained python script, I'm grateful for the exposure to such complexity.
philbarr 12y ago
I've always found that the people who write the AbstractFactoryFactorySomethingVisitor patterns are the people who read about design patterns and want to use them for the sake of using them, because they think it makes them better developers. Instead they should learn about design principles, and instead of thinking "which pattern should I apply here", they should be thinking, "what is the best way to create this code so that the basic design principles are upheld". You can start with SOLID principles and go from there. The same happens with language features; when generics were introduced, everyone wanted a generic class for some reason when it's almost never needed outside of the Collections framework (bit of a sweeping statement but I hope you see what I mean). In fairness, I don't think it's really Java's fault, only that it's been around long enough for there to be many more examples of this kind of thing. I've been working in Java for 15 years and C# as my day job for the last 3 - you can easily pick out examples in C# where the langauge has been abused: dreadful LINQ expressions where a simple for-loop would suffice (and be quicker), or multiple Events added to a class, ALL of which need to be hooked up by calling classes for it to be usable, so an Observer really would, actually, have been a better solution. I've played around with functional programming and there are a lot of claims around how it forces programmers to write better code. I'm not sure how it's going to stop programmers abusing language features or the language characteristics, though. I may well be wrong about that and am happy to be put right by a knowledgable FP dude.
dmacvicar 12y ago
While I have seen what you describe, I am not sure if it is only specific to Java, and I have to admit that I enjoy working with the Java platform. There are things in the ecosystem that annoy me more. We use Java in a non-standard environment: products built on a enterprise Linux distribution, and therefore built using the same infrastructure and conventions: everything is built from source as a dependency chain, so that you can patch it and provide support, and ship those patched components back as packages. Everything is built in a repeatable environment, jailed in a VM, no network, that only contains the dependencies you declared. So there were those nice times where building a Java library meant packaging 2 or 3 dependencies, then packaging the library was as simple as unpacking, apply any patches, set the classpath to the dependencies and run ant. Then install the resulting jar. It played well with the environment. Java build tools are insane. To build most libraries I now need Maven. Maven needs like a hundred dependencies to build, plus some plugins that need those dependencies, and those plugins build with Maven, the dependencies too. At the end, to build Maven, you need to have all components which are the reason you are building Maven in the first place. So this makes me thing Java developers don't think in terms of layers, and they pull dependencies without balancing the costs (writing one function vs depending on 20 more jars). A build tool should have almost no dependencies outside of the base system (in this case the JDK) and the compiler. But no, they added even a Dependency Injection container. And now they realized that the one from Google is better, so they switch to it, but without removing the old. So now they may be depend on 150 packages instead of 100. Great. Lets add more stuff. Imagine if to build make you need to have Gtk, and a library that builds with cmake and another library that builds with scons. And all the noise with this advanced nuclear engines and frameworks to power something as simple as a build tools is at the end useless. At some point the project still declares technical bankruptcy and dies. Java has a lot of "choice" in terms of libraries, but a good percentage of them are dead projects.
- mike_hearn 12y ago
  Are you really generalising to an entire industry from the build procedure for a build tool? Why are you even building Maven in the first place? My experience with Maven has been: 1) Download and unzip 2) Run it and that's all that was necessary. Meanwhile on the fly dependency resolution is very nice and a feature of most modern platforms.
arel 12y ago
As the author said its not the languages fault. And if you know what you are doing then Java is clean, mature, performant, dare I say it enjoyable platform to use. I think there also a generational conflict here. Java is a development environment that was born in the big architecture and 'development as enginerring' era of the late 90s. Spring was a reaction to the over engineered J2EE and now even Spring, the early liberator is considered over engineered. Its our dad's language. There is still a certain mindset from that era that was conditioned by the GOF and Universities and amaeteurs churning out developers but it is increasingly rare. In fact I find Java is amongst the most interally introspective and disciplined in terms of coding taste and style. I can almost guarantee if I look at another Java developers codebase that I can follow their code structure and style without too much effort. I'm not sure that would be the case for the large amount of very individualistic FP code being generated currently.
pjmlp 12y ago
Java is not the problem, enterprise architects are. If anything, Java allowed the so called architects a much easier path to such crazy skyscrapper designs than any enterprise language before it. So of course they went crazy with Java, and later on C#, because it was so easy to do so, without being caught in core dumps and similar issues. Anyone complaining about enterprise Java, just needs to go back a few decades to see what was being done in C, C++ with CORBA/DCOM, VB/Delphi, CLIPPER and tons of wannabe 4GL languages. Any language that wins the hearts of enterprise architects will suffer the same pains that Java is known for. I can already imagine a "Enterprise Functional Design Patterns" and similar books.
- mike_hearn 12y ago
  Ah yes, DCOM. That was truly the domain of the C++ enterprise architect! Today's AbstractProxyFactoryBean was yesterday's IDispatchProxy, IRPCProxyBuffer and so on. What's scary is that big chunks of heavy industry are all standardised on it via OLE for Process Control (OPC).
  - pjmlp 12y ago
    Thanks to WinRT is it back!
- revscat 12y ago
  > I cannot agree more. At this moment I have an interface open with the following signature: public interface ClientBenefitOrder extends Internationalizable<ClientBenefitOrderDisplay>, CBMEntity, Enableable<OfferCategories>, Deletable, Comparable<ClientBenefitOrder>, ClientOwned This is entire application suffers from Enterprise Architechtitus, and like OP I have encountered that far too often for it to be a simple mistake. There is a cultural tendency in Java land towards overengineered solutions. It's pervasive. It also makes for bad code.
zmmmmm 12y ago
It will be interesting to see if Java8 inspires a fresh look at the design approaches used in the Java world. So many of those over-architected Java designs are trying to solve lack of flexibility and expressiveness in the language. There's an opportunity now to keep the good and move on from the bad ... it's terribly unfortunate though that it's not clear if Android will ever properly update from Java6 syntax. If it doesn't a large amount of the Java ecosystem is never going to move on from there.
frugalmail 12y ago
I'd much rather have a large application written in OO w/ Java then a functional only application. I have serious concerns about maintainability otherwise. This is of course assuming that we have good developers on either side. Especially when the language in question is getting libraries and native features that pull in the good parts of other languages. Blog posts like these make stupid generalizations. I'd also like to say if 5% of the Java Developers are the good developers that would be factors more than 100% of the Clojure developers + 100% of the Haskell developers + 100% more than the F# developers.
kasey_junk 12y ago
Wow there is a lot of bashing of the GoF patterns going on here. It seems like lots of people have a misconception about what patterns are. Patterns aren't a goal to meet with your software. They are common emergent solutions to standard design problems. The GoF didn't invent them, they just cataloged and provided a standard name for them. So once we have a common name, shouldn't we use it? If I see a FooFactory, I have a pretty good idea what to expect in that class. So the problem with a FooFactoryFactoryAdaptor isn't that it is following GoF patterns or in it's silly name, it's that you have a solution that has at least 3 levels of abstraction. The patterns didn't cause that.
CmonDev 12y ago
You can use Xamarin (C#, F#) for Android though, which will let you go multi-platform in future.
oldmanjay 12y ago
well nothing convinces me like unsupported assertions and undirected insults. I now hate java as well.
louischatriot 12y ago
Interesting read, explains well why I don't like to code in Java anymore. Most Java devs who go too deep in frameworks and complexity should try to build a small project in a very dynamic and concise tech. I always recommend Node.js for that, since you have to selcet the right module for every job, have to think it through and really understand what's going on, and can easily step inside the code if need be.
pramalin 12y ago
I think the author is out of touch with modern Java development practices. Any decent Java developer would have got exposed to POJO based development[1] by now. [1]Expert One-on-One J2EE Development without EJB - Rod Johnson, 2004 These days even the much hatted EJBs are POJO based and lot easier to work with. Not to mention Lambda support in Java 8 and the hybrid approach of Scala, my favorite.
- jeremyjh 12y ago
  I think the commentator should read the article. The author does not once mention EJB. The problems he describes are endemic to all kinds of libraries and frameworks and are VERY much a part of most shop's interpretation of "modern" Java development.
jaxytee 12y ago
For Android developers interested in building apps in Scala check out Scaloid: https://github.com/pocorall/scaloid https://github.com/pocorall/scaloid.
larsmak 12y ago
I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, android, etc. I've used lots of frameworks like Spring and Hibernate. Although such frameworks often provides abstractions and encourages usage of design patterns, I've never really found my-self getting lost in their layers of abstraction, and I've can't really say I've come across any "AbstractAdapterFactoryProviderBean"-either. I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past. When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.
- lnanek2 12y ago
  I can say the same re your experience, but I kind of experience the same thing he links to with Gradle and really despise it. Handling the constant Groovy errors and Gradle errors, and spending my life digging through their docs for a language and a build system I couldn't care less about really depresses me when I'm a Java expert. Give me a stack trace and I'll have the problem fixed in five minutes with unit tests and UI automation tests done later that day. But give me a gradle error and I'm stuck in their docs all day, you might have a solution this week. And by the way it breaks automatically all the time as Android Studio and the android tools plugins and all the rest version up. I wish we could have just stuck with Ant and Eclipse for Android, which are known evils. Instead every update of Studio and Gradle someone on the team has to draw the short straw and try, then either give everyone else the OK or tell them to stay the hell away from that version.
hawleyal 12y ago
I second and third everything he said.
virmundi 12y ago
Having worked in the Java world for the past 8 years, I think the issue with the developers is that the work is boring and they want to solve some problem. Folk who work with Ruby (at least 2-3 years ago) were doing something interesting. It could be a simple CRUD app, but Ruby made it interesting. People wanted to be there. Java is not. Instead, Java has a history of patterns for the sake of interest. Need to inject something in? Use a FactoryFactory. Most of what Java becomes revolves around having to do tedious CRUD apps for the enterprise that constantly change what they want.
sigmaml 12y ago
> More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit. It is sad to see such strongly-worded blanket statements. The author generalises his experiences with Java to entire OO. He doesn't, unfortunately, seem to realise that non-Java OO does exist. Also, several lean Java frameworks exist, without deep class hierarchies and factories of factories. Finally, OO is one of several possible ways to modularise and scale code and teams. FP is another. As languages like Scala have been demonstrating, it is possible to selectively blend features of both in fruitful ways.
robmccoll 12y ago
So happy to read this, yes, yes, and yes. Another big problem with Java to me is that the standard library and available frameworks are so massive, that there are thousands of ways to solve any given problem. This is bad, because only a handful of the solutions perform well, result in readable well-written code, and are efficient (from both a productivity perspective and resource utilization perspective). I'm not sure why, but it seems like many developers are almost trained to pick the bad ones. Perhaps the high level of abstraction enables the programmer to ignore the realities of the implementation?
bmoresbest55 12y ago
As a newly hired Java dev I can understand the problems that Java has with many levels of unnecessary complexity. However, I do not think it is right to simply say that all or even most Java devs are bad. First of all the definition of bad is relative to the person and secondly I would not agree in saying that they are all or mostly bad. People are usually trying to do the right thing and if that does not fit inside your ideals then it is bad? I guess all I am saying is not the throw stones. No one is perfect and to bash a whole community today based a snapshot of what you have seen is narrow-minded, look for the good parts and focus on those at least. Teach someone to code well in Java, if you feel so inclined to say that you know better. I know that there is a lot to learn, personally. I currently do like Javascript and Python as well but I would never look down on Javascript, Python, or Java communities. They are all great in their own way and in many similar ways. We all enjoy coding at some level, why does anotehr way of doing that have to be so worng?
cromwellian 12y ago
I think most of the problems are caused by enterprise, enterprise frameworks, and the sheer age of Java. There's a lot of technical debt built up and a lot of enterprisey frameworks that are way over engineered. I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc. I think the article is right in one important aspect: the way Sun built Java was to pretend as if everything should be a competitive market. So pluggable drivers for everything. Rather than build in say, one XML parser, instead let's build in a whole system to allow you to plug in any XML parser. As a result, it takes 4 lines of code to do what should work in 1 line. On other platforms, Python, Ruby, Go, et al, there is no such assumption that one needs an abstract interface to allow multiple implementation providers. You have an opinionated built-in implementation, or you use third party APIs. This is why you have stuff like DocumentBuilderFactory/DocumentBuilder/etc. When really, you want to write: Document doc = XML.parse(...) Enterprise developers copied the basic design of having provider lookup/locators. This is why we have AbstractFactoryLocatorServiceLocator stuff. Where I part company with the author is the total trashing of OO and the language. There are certainly lots of warts and things to complain about, but I haven't used a single language where I didn't have a boatload of things to bitch about. I think you fall in love and there's a honey moon period with most languages, and then the beer goggles wear off after daily use and you see all the flaws.
- josho 12y ago
  You are bang on. It reminds me of the opposite take that we've seen in browsers as of late. Eg. innovate with webkit specific extensions then standardize what works. Java meanwhile standardized conceptually useful concepts (Swing, Java Server Faces, etc), but the markets for pluggable Swing or JSF components never took off. I think it's that under Sun's direction the intent was to create markets, e.g. a market for GUI components or web components, a market for server components (EJBs). At least in the case of server components, Sun made a lot of money by licensing J2EE servers. I suppose that was their motivation all along for forcing DocumentBuilderFactory's on developers.
- tootie 12y ago
  Java is not designed to solve programming problems, it's designed to solve organizational problems. And it does a pretty good job. That's why you see lean startups shunning it then slowly migrating when their company gets too big.
uptownJimmy 12y ago
Recently-graduated student here, middle-aged and with more than my fair share of life challenges under my belt. I fell in love with coding by accident, after half a life in the restaurant trenches. But one of the things you can learn in the trenches is the value of patterns, and the value of recognizing patterns. Over the years I've come to trust my instinct for recognizing patterns, hard-won as it was. Java is swamped in an over-proliferation of verbiage. That is the first impression one has of the language in school: that it requires twice as much code to do anything. And that was, as well, my last impression, as they tried to prepare us for our entry into the world of enterprise computing by steeping us in a rolling, boiling stew of jEverything. Too many cutesy names in a programming language just felt WRONG, and I think my instincts have been borne out. Java is a mess to behold and to work in, and I am fantastically glad that I didn't get that first (Java) job I applied for, but instead got the second (ASP.NET) job. Irony abounds, I know, but .NET seems streamlined and elegant compared to Java EE. Turns out, sometimes you actually CAN judge a book by its cover. And by the 1496 pages in that Java textbook, which, hysterically, serves as merely an introduction... I don't know where I'll be in a few years, but I'm fairly certain I'll not be coding in Java.
lkrubner 12y ago
Java combines OO with strict typing (unlike Ruby which has OO without the strict typing). As such, that particular combination leads to bloat and verboseness. See: What did Rich Hickey mean when he said, “All that specificity kills your reuse!” http://programmers.stackexchange.com/questions/199217/what-did-rich-hickey-mean-when-he-said-all-that-specificity-of-interfaces-cla http://programmers.stackexchange.com/questions/199217/what-d... Part of the answer given: "If you have two entities { "name":"John" } of type Person, and { "name": "Rover" } of type Dog, in Java-land they probably cannot interoperate unless they share a common interface or ancestor (like Mammal, which means writing more code). So the interfaces/types here are "killing your reuse": even though Person and Dog look the same, one cannot be used interchangeably with the other, unless you write additional code to support that. Note Hickey also jokes about projects in Java needing lots of classes ("Who here has written a Java application using just 20 classes?"), which seems one consequence of the above."
- frowaway001 12y ago
  > Java combines OO with strict typing [...] > As such, that particular combination leads to bloat and verboseness. It's bloated and verbose, because Java isn't very good at it, not because it's a fundamental issue of OO with types. > in Java-land they probably cannot interoperate [...] Ditto.
mark_l_watson 12y ago
I agree with the general sentiment of the article. I have used Java since the beginning and I have written many books using Java for the examples in the books. I mostly use Haskell and Clojure (with little text utilities in Ruby) now, but I still do find that Java is sometimes the best language for some projects. Off topic, but Java 8 streams and inline functions made the language better. That said, I no longer use Java in any sort of "standard" way. I stopped using getters/setters years ago in favor of public instance variables. I also write a lot of static methods ("functions"). Basically, I try to make my Java code as concise as possible. I also have turned my back on large server side frameworks. For web services, embedded Jetty and a JSON library is often all the library support that I need.
critium 12y ago
I actually have a different problem. Java developers that are IDE jocks and dont have any kind of understanding of what is happening underneath the API. Take these guys outside of the IDE and they dont even know how to compile the code.
kyllo 12y ago
The language has some very poor design decisions baked into it (read: no functions) but the biggest problem with Java is that it's the lowest common denominator enterprise programming language, and managers have used it to lower the bar in their attempt to commoditize programmers. As a result there are lots of Java programmers on the market, with low salary expectations, and the code they produce is of commensurately low quality. As Paul Graham put it, Java is a language you learn to get a job. Do you want all your company's code to be written in a language that your programmers only learned because they needed a job?
zkanda 12y ago
I heard Kivy is getting more popular, that is if you like writing in Python.
kaonashi 12y ago
The dependency-injected style is great for mitigating side-effects and avoiding hard dependencies in code. The problem is that it's a poor substitute for currying and composition.
- _pmf_ 12y ago
  I agree.It's good design in the disgusting veneer Java requires.
michaelochurch 12y ago
One problem with Java is the 15+ years of bad taste. Design patterns are "revenge of the not-nerds". It's "I don't know what a monad is and don't care to learn, but I'm going to make you feel the way I do when I see math by renaming the sine function to VibratorVisitorFactory." Moreover, Big Software is generally a bad idea. There are occasions where large programs are a good idea, but the default should be small, composable units. Scripting and batch jobs aren't "baby coding". They should be the default unless you need a long-running server process. Most programs (over 90%) should be doing one thing and doing it well. The problem is that people don't code this way because it's better for enterprise managers' and architects' careers to say they oversaw gigantic, overarching software projects. I've actually noticed that data scientists, while their line-by-line coding skills aren't as good as a professional software engineer's, are usually much better designers (and far better communicators) than Java engineers. Sure, R is janky and Python has ugly corner cases, but data scientists write programs to do specific tasks and generally are good at keeping code small (because they have a personal responsibility for the code-- if they can't read it, it's basically lost-- not experienced by "architects" who can hire maintenance engineers to clean up their messes). You don't see the enterprise "software for software's sake" problem. The result of Big Software tends to be Java Shop Politics, as described here: http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/ http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol... . It's not the fault of Java. It's just a bad way of writing software.
- thecage411 12y ago
  I've noticed that the combination of math and communication skills is pretty well correlated with producing clean designs and code. Data scientists probably have those skills more often than programmers, but I'd argue that it's the skills rather than the culture that account for the difference you are seeing.
jdennaho 12y ago
I've worked with java for 10 years now... I have seen some shit let me tell you.
curtis17 12y ago
I totally agree with the original poster. I picked up Java in the mid-90's for server-side dev. Grew to loathe it. When Google announced an open-source OS for mobile - I was so happy. But ... Java. Broke my heart. Don't Google have any taste. At least Google could bless an alt-Java Swift-ish alternative like Kotlin, Xtend, AnythingButJava.
- mike_hearn 12y ago
  They don't really need to bless it, do they? Any JVM language that targets Java 6 should work.
  - curtis17 12y ago
    Google have issues with Oracle. Why not bless an alt-Java and give developers a clear signal. The end game should be Kotlin or Xtend or ? -> Dalvik/ART. Cut out Java.
    - wstrange 12y ago
      Dart for the win
      - curtis17 12y ago
        Dart is interesting but a little too Jave-ery in both syntax and tools - Dart Editor is Eclipse based. Also, not sure how committed Google is long-term. Google's issue is too many languages and runtimes: Go, JS/ES6/V8, Dart/DartVM, Java/ART, PaNcl, RenderScript. With the Material/Paper UI Google have given dev's a consistent, elegant unified surface. But Google should also be moving in the direction of an (elegant) unification under the hood. Java and JS are 20 years old - but are at the core of Google's platforms - Android and Chrome/OS. But what - Kotlin, Dart, ES6/7?
kizer 12y ago
As a relatively young programmer, I feel that I'm just now exiting this stage of over-abstraction and pursuing a "perfect" design. Perhaps it does plague many older programmers, but to me super object oriented programming was a sort of programming puberty. In high school, I would sit down to write a Java program and figure that I would have to construct this grand architecture where each class reused absolutely no code and fit perfectly in an abstraction hierarchy. Of course, I would quickly lose focus of business logic and write a gazillion SomethingSomethingRepresentation classes and get nowhere. It really hit me when I realized I had a file named Null.java :)
talles 12y ago
> "(...) OO is actually pretty shit (...)" Relief washes over me in an awesome wave when I read this line. No, no, I'm not attempt to mindlessly bash OO. But I've worked over the years with folks that put OO as some sort of holy rules. When arguing X vs. Y the discussion goes well until someone says "Y is wrong, Y violate {this} of OO", shit, when that little statement is made I know I'm lost. Because even if I attempt to show that in this particular case violating such principle is good, I am doomed to be considered a heretic, an outsider, and sometimes automatically a bad programmer. I've tried to not thought of my self as an 'enlightened', but people kept acting as believers of such religion over and over that I could help myself sometimes. It's pretty much the feeling of being a philosopher teacher in mormon cult of something.
JAlexoid 12y ago
"Android - really the biggest reason today why anyone besides the enterprise guys cares about Java anymore" This line just says - ignorance. Thee is a *tonne of stuff in Java. And just because the majority of developers are low quality(what language does not have that?), does not diminish the interesting stuff that is going on with the whole platform.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
maxwin 12y ago
"I’m an Android developer, stuck using Java. It’s breaking my heart." Glad that I am not alone.
- curtis17 12y ago
  Definitely not alone. At the Google IO Android Fireside Chat, a developer asked the Android team about using an alternative to Java for development - Scala in his case. Pretty much 'no' was the response. But don't Google have any taste. Kotlin or Xtend imo are lighter than Scala and would be good fits for Android.
rbanffy 12y ago
Not only Java. I die a little every time I see a PHP application trying to cargo-cult common Java overdesign patterns because "that's how 'Enterprise' apps are built".
peterashford 12y ago
I have been using Java for a really long time. I have never seen a "AbstractAdapterFactory" anywhere. Ever. Disclaimer: never did any J2EE BS.
lukaseder 12y ago
As the article states, this isn't a general Java problem. Just a problem of people copy pasting horrible code suggestions (or design suggestions) off some vendor's tutorials. Here's a blog post that shows how to make a game out of that madness we have gotten used to thanks to JEE / Spring http://blog.jooq.org/2014/04/01/spring-api-bingo/ http://blog.jooq.org/2014/04/01/spring-api-bingo/

256 points by nsainsbury 12y ago

Good read - the bit about Android is spot on.

Java hits a sweet spot of simplicity, platform stability, safety and performance. Also, its popularity in the enterprise is partly because interchangeable, cog-in-the-machine low quality developers can be productive in it and not cause too many meltdowns. Thats an economic advantage! If you need lots of cheap developers for your IT department, good luck finding 15 Clojure and Haskell gurus. I say that as a Java developer, btw.

ayrx 12y ago
Isn't it just a little sad that the biggest selling point of a language is that mediocre developers won't cause too many problems with it?
- adamors 12y ago
  It's not sad, because most developers are mediocre. It may not apply to you, but if you work in the industry long enough you realize that very few of your colleagues are good/great. And there's nothing wrong with that, but if you want to build systems that have to be maintained over multiple years, you somehow have to compensate for that. Java is one compensation.
  - MrBuddyCasino 12y ago
    Exactly. By definition, most developers are mediocre, and thats okay. Platform stability and limiting complexity is really important in the long run, so (luckily, imho) C++ and Scala are non-starters.
    - Dewie 12y ago
      > Exactly. By definition, most developers are mediocre, and thats okay. That doesn't say much. So yes, most developers are average, but what is average? Is it necessarily developers who need training wheels, helmets and elbow pads in order to protect themselves and others? That may be the reality, for all I know. But that isn't necessarily a timeless truth. Take a room of expert programmers; now most of them are mediocre (average), relative to each other (imagine a really big room with a lot of experts, if you must). But that doesn't necessarily mean that they need languages that cramp their style in order to mitigate whatever damage they might do. "Mediocre" is the same as "average", but with more negative connotations. Hence, when someone says that some people are 'mediocre', the immediate thought might be "bad". Then it becomes obvious that tools need to hinder these bad developers from screwing up too much. But mediocre is just a relative term, and can mean that they are really bad developers who create 100 bugs for every feature they implement, or that they are really competent, reliable developers. I won't comment on the skill of the average (mediocre) developer. But I think that saying "most are mediocre" can easily hint at "most are bad" (because of connotations, not necessarily because that was the intent).
      - MrBuddyCasino 12y ago
        True, there is a negative connotation there - maybe using that term was a mistake. There certainly are huge variations in baseline skill depending on location and line of business. I was thinking of the more or less generic enterprise software environment in firms whose main business is not software development, and which reside outside silicon valley or other tech hubs.
dozzie 12y ago
Simplicity -- none, if talking about the resulting code. Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Performance -- poor, regarding memory consumption. Indeed, the sweet spot. > If you need lots of cheap developers [...] Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent. It's the same hard finding decent Java programmers as it is with Haskell, except that Java scares good devs away and Haskell attracts them.
- dtech 12y ago
  > Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Do you have actual examples of companies using Java for their run-of-the mill software that have been hit with lawsuits from Sun/Oracle? The only two I can remember are Sun vs Microsoft (because of proprietary extentions) and Oracle vs Google (complex licensing issues). Sounds like FUD to me.
- matthewmacleod 12y ago
  Simplicity -- none, if talking about the resulting code. Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot. Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Bollocks. I challenge you to provide an example of a Java developer being sued for using the language. Performance -- poor, regarding memory consumption. Bollocks. Uses more memory than C, but no manual management. Sweet spot. Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent. Bollocks. In my experience, they're likely to be somewhat better skilled and educated. They're also far more likely to spend their time arse-ing around trying to implement an elegant, concise solution to problems which only exist because of not-invented-here syndrome, or because their language lacks as extensive a standard library. As an example, I once worked on a Mac GUI app for a company - bog-standard, nothing fancy. I took over from a developer who had been trying to build this using Racket; this involved building a Qt-Racket interface, which involved magical automated parsing of C++ header files, which meant… basically, not delivering a product. Meanwhile, the Objective C build was done. The point is, there's far too much focus and snobbery about what tools developers use. There are loads of languages out there; pick one that has a reasonable amount of support and fits the problem domain, and build simple, maintainable code. You can do that in any language.

Hermel 12y ago

There is a lot of Cargo Cult programming going on among Java developers. Why using a simple constructor when you can use the factory design pattern? Or why directly instantiating a logger using the "new" statement and the right arguments, when you can also configure it using xml files? Making use of design patterns and frameworks is professional, after all, isn't?

dozzie 12y ago
Actually, configuring logger with values stored in a separate file instead of hardcoded ones is a good thing. Logging configuration is configuration, after all. You wouldn't want paths to documents be hardcoded in your office suite, would you? Or target address of VPN gateway in VPN client?
malka 12y ago
over the years, I developped a fiery hatred of XML configuration files.
- kasey_junk 12y ago
  and I'm starting to develop a fiery hatred for JSON configuration files. At least XML had standard support for schemas and querying.
- virmundi 12y ago
  Over the years I've developed a deep understanding for why XML configuration is great. Java's move to annotation, upon annotation. As a result there is no single, canonical place I can go to see what the general configuration is. I have to track through classes, that may or may not have a good structure to find a specific instance of a route. Spring 3.x configurations, with inheritance are wonderful. The only work is to follow the imports.
DCKing 12y ago
Your statement sounds like a reverse cargo cult. The problem is not that people use these constructs that you mention. The problem is that people use the wrong constructs at the wrong time, don't seem particularly good at judging which to use when and just use the most convoluted one by default. There are many contexts in which the factory pattern is the best choice (although not the majority) and in which configuring logging externally is the best choice (almost always).

lukabratos 12y ago

Knock, knock. Who's there? Long pause ... Java!

TeeWEE 12y ago

While I do agree that java developers are often low quality developers. And than java frameworks are often bloated with Dependency Injection, Factories, Proxies etc... I disagree that Android has the same problems. To me it looks like Android was actually written in lean-and-mean java. Ok its still Object Oriented. But for UIX interfaces, Object Orientation makes a lot of sense... There are some areas in the android API that are indeed a bit bloated. And that is indeed inherent to java.

boobsbr 12y ago
> While I do agree that java developers are often low quality developers. That can be said for ANY language.

nick_riviera 12y ago

I disagree with this, as a part time Java developer (I do C# most of the time). The points I disagree with: 1. OO is bad. Every paradigm is bad if you misuse it. If you build deep abstractions then you will hang yourself regardless. Some very elegant and simple designs can emerge from OO code, but only if you think about the problems first. The majority of pain consists of forgetting to do that step. There is no magic bullet - FP has its own pitfalls as well as does simple procedural programming. 2. Everything looks like it's written by an architect. Well that's a broad generalisation and I'm sure some people titled architect would be sick at the association (considering they usually reduce complexity) but the problem here is that people aren't using the frameworks properly. Not joking but the last two or three Java web applications I've put together have virtually no code in them. It's just the domain model, the views and query encapsulations. Nothing else. The abstract factory factory factory factory crap isn't your problem. If you make it your problem, then you're just doing it wrong or not using the tools provided efficiently. 3. Android. Android is abysmal (I've written a couple of things for it so far), but that's not because of Java but the fact that the Android API and versioning mess is a pile of unstable crap. It'd be nice if there were't so many exceptions. If you're going to pick on Java, at least jump on: Idiotic code on the web, Glassfish being a right pile, view technology being foul, servlet container reloading, Swing/JavaFX or Eclipse...

signal11 12y ago
Some of the complaints about the over-formal language is a matter of taste, perhaps, but it does grate and is not a new complaint (see also: the Kingdom of Nouns rant). However Java developers are learning (or migrating to Scala/Groovy/Clojure). And there is hope -- the Play framework, for example, is an example of Java done right (imho). Spring 4 is moving in the right direction.
- nick_riviera 12y ago
  I don't think it's a matter of taste. TBH I write very little of the code that is checked in to the source control. The IDE does all the boilerplate. I literally design the method signatures, define the access policy for the methods and fill in a few gaps here and there. Play is not Java done right by any means. It's tightly coupled, has really poor documentation, breaking changes galore between major releases, deployment is trouble (compared to tomcat) and rather tied to Scala's API. Java done right is picking some lego bricks that you stick together to get what you want and telling it how to wire them up. YYMV but 99.9% of all problems are already solved off the shelf.

skrebbel 12y ago

A lot of these bloated patterns that got popular in the Java world have shorter, simpler alternatives when programming in a functional style. You often don't need multiple child classes to implement a template method if you can just pass a function to the constructor. You don't need a BananaFactory if you can just inject a createBanana function. Remarkably many Gang of Four design patterns are unneeded once you can pass functions around. The C# world is now learning this: when C# 1 and 2 were popular, the ecosystem went right after Java in the kinds of boilerplate that the author describes. Now, many years of Func and Action goodness later, there's a large part of the community that codes way more to the point, and this part is growing. People who release C# libraries in 2014 with factories adapters and multiple layer inheritance hierarchies are laughed at. Since Java 8, Java too has an accessible way to pass functions around. Not really functions, because Java, but in practice it works the same way. This means that there's nothing technologically that's holding the Java community from making these improvements, too. I hope it happens.

icebraining 12y ago
I don't think Android supports Java 8, though.
- Alphasite_ 12y ago
  I thought there was some work to support Lambdas in ART?
  - on_and_off 12y ago
    There is a retro-lambda library that allows to write lambda expressions. It is compiled to jdk 6 compatible bytecode though.
- needusername 12y ago
  I don't think Android supports even Java 7. Sure, maybe source level but AFAIK invokedynamic and method handles are still missing.
- mike_hearn 12y ago

markokrajnc 12y ago

Disclosure: Long time Java programmer here (since 1996, previously worked many years with Smalltalk). Java Language and Java Virtual Machine are great, but Java Libraries are in many cases too complicated (using too much of "Gang of Four" patterns).

seanmcdirmid 12y ago

> The OO craze has a part to play in this madness as well. More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit. Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do. > Even today you’ll still find a strong bias towards OO courses being taught at the university level using Java, and the bias was certainly stronger 5 - 10 years ago. Because that's what people use to write real programs. > The engineers at Google working on Android are too busy architecting grand frameworks for solutions and not busy enough solving actual problems. Because we all know, Google is known for hiring flakes who can't code or design real systems. Worse is better means getting things done even if your tools kind of suck or your understanding of the problem isn't yet great. It leads to architecting and less than ideal solutions, but at least you ship!

DCKing 12y ago
There seems to be an implication in your comment that people aren't using FP to write "big serious programs". Is that really what you are implying?
- seanmcdirmid 12y ago
  In that domain, yes! How many UI frameworks are functional (beyond I think...Om?)?
  - agumonkey 12y ago
    Let's wait and see if Om inspire others. You know that ideas take time to diffuse, OOP/MVC has been a somehow natural fit for IHM, but like many other ideas (closures?) now that people can see it, maybe they'll change their mind.
  - DCKing 12y ago
    It's unfair to focus on "UI frameworks" when UI frameworks are specifically aimed at supporting client OSes where they have to deal with "preferred frameworks", all of which were developed when OO was all the craze. Functional programming has only been discovered as a practical paradigm quite recently! Besides, implying that "big serious programs" necessarily implies that they are UI programs is completely wrong. Unsurpisingly, if a given JS UI framework is OO, it is not OO in the traditional sense because JavaScript itself is not OO in the traditional sense. If you make a framework, you use the language of whatever runtime you are targeting. Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those services have less baggage of trends than UI heavy programs do. So you are arguing that there is some perceived evidence for OO in UI programming, but I think that could more easily be attributed to historical trends. Note that I'm not necessarily disagreeing with your conclusion, just that your reasoning is flawed.

_pmf_ 12y ago

The proliferation of factories is not an indication of over-architecting something. It is a direct consequence of finding a balance between maintainability and the lack of first class functions (or constructors as first class functions). If you have never had the need to introduce factories, I claim that you have not worked with a truly polymorphic system.

mobiuscog 12y ago

I agree with much of the article (also as being a java developer for the last 17 years). However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem: Frameworks. Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is at an all time high), and often code following 'best practices' handed down from academia/conferences/books that promote large abstractions which are often un-necessary. It's similar to how C code would end up having pointers-to-pointers-to-pointers-to-pointers... A whole generation (generalising/stereotyping, I know) is now coding, who have never grown up and learnt with basic logic gates and low-level code. The framework is the obvious choice because 'why would you want to write it yourself, if it exists' ? (Ironically, many Javascript developers seem to be intent on re-inventing everything that's gone before, and it's somehow seen as innovation - go figure) Grumpy old man ? Sure, I am. I'm also gladdened to see a recent upsurge in assembly language and other low-level coding, as this is what the world actually needs - less super-business-entrepreneurial startups, and more people able to actually solve real problems and not just hipster entertainment.

UK-AL 12y ago
Assembly, and Low Level Coding is the exact opposite of solving 'real' problems. Your going low level to create problems that didn't exist, as opposed to working on the core issue(often business related) your software is trying to solve. Languages should allow you to focus on creating software that fixes a real world problem, as fast and cleanly as you can. That doesn't include bit flipping, or bit operators or anything like that unless required. People should be working in super high-level languages like Haskell, OCaml, F#, Clojure, or languages that fit their domain perfectly. The goal is to fix problem the as concisely and quickly as possible.
- dbaupp 12y ago
  Writing low-level code is important for writing the underlying libraries for those high-level languages, e.g. the run-time systems or the big integer routines.

therealmarv 12y ago

Java can be really glad that there is Google with Android. Otherwise this language would be a strong enterprise focused language with very bad reputation on the end user side.

andybak 12y ago
However - how many developers are turned off of being Android devs by the fact they have to use Java? (and I know that probably many more are attracted because they already know Java but that's not my point)
- watwut 12y ago
  I was turned off by a.) horribly slow speed of Android virtual machine b.) being hard to code for it with maven c.) I did not particularly liked their xml language for gui. I would have to write mobile, I would use one of those languages that compile into both Android and iOS as much as possible.
  - cerberusss 12y ago
    Exactly. I personally think Java is fine. It's just that the development environment is much less nice than Xcode.

thescrewdriver 12y ago

I've been using Java for about 15 years and largely agree with the article. The verbosity of the Java language is definitely part of the problem, although that aspect is downplayed in his blog post. I agree with the author about the culture. Java programmers in general seem to be on some sort of design pattern frenzy, especially in the better known frameworks. It doesn't matter if you're writing a fancy framework or writing a trivial app to process a file, chances are you're going to see layer upon layer of over-engineering. I switched to Scala a couple of years back and have never been happier. Only part of the improvement is due to the language the other part is not having to deal with Spring, builder patterns, and madness like AbstractSingletonProxyFactoryBean [1]. My impression has been that the typical Scala developer has had lots of Java exposure and has learned from their experiences. [1] http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...

__Joker 12y ago

Can't agree more. The problem is not the language itself, rather who uses and whats the culture associated with it. Java is mostly used in the enterprises, where unfortunately thest "architects" exists. Architects are nothing but people have grown out of the roles and in a way of organization recognizing the peoples talent. Most of the times the Architects are redundant. Most of the cases use of Java is nothing but writing your business logic into the Java code. Unfortunately, architect to justify himself would try to engineer a solution, which never needed engineering itself. and down you go in the rabbit-hole of oops and abstraction. Unfortunately it will be pretty hard for Java to shake up this image.

threeseed 12y ago
Good architects play a vital role in the organisation especially if you have a sprawling set of agile teams that don't necessarily work together. There are plenty of really tough integration, security, scalability and performance challenges that need someone who is across the entire stack from very top to very bottom. You rarely find developers who can manage it all and still find time to cut code.

jackhiggs 12y ago

The real problem is developers not understanding Object Oriented programming. Many developers write procedural style in Java or any other OO language. So you get God classes, methods that are hundreds or thousands of lines long etc - I'm sure we've all seen those horror shows. It's just a lack of education coupled with a culture where there is no strive for technical excellence. You need high quality developers in Java, just as you do in any other language. It seems like the article's beef is with OO programming, not Java per se.

vijucat 12y ago

Blame the 90s : the Gang of Four design patterns book, UML, et al. If you wrote code that did not abstract enough, such as not using factories, it was jaw-droppingly obvious to your colleagues that you were not good enough. FP and Scala owe the sheer verbosity of Java a lot for their current success :-)

pjmlp 12y ago
Targeted at C++ and Smalltalk developers.
tormeh 12y ago
God. UML.
cam- 12y ago
Java has been round long enough to have been influenced by whatever was the coding fashion of the time. You can see it in the core java libraries and the supporting frameworks. OO and GoF where probably the biggest fashions and you can document when a core library was written by the approach to it.

moretti 12y ago

I think this code truly represents the essence of this article: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

jimmcslim 12y ago

Great article, but I especially encourage you to read the one before it as well... http://nsainsbury.svbtle.com/leonardo-da-vinci http://nsainsbury.svbtle.com/leonardo-da-vinci

mlangdon 12y ago

I for one appreciate the hard work that was Android and Java. I spent two years intensively self-teaching, primarily on Android before starting my developer job. Having to take in large, unwieldy systems with lots of moving parts was mind expanding. I could spend a night in the API, go to bed and wake up feeling smarter. I haven't done any Android for my job (and just a little Java), but every time I have to design more than a self-contained python script, I'm grateful for the exposure to such complexity.

philbarr 12y ago

I've always found that the people who write the AbstractFactoryFactorySomethingVisitor patterns are the people who read about design patterns and want to use them for the sake of using them, because they think it makes them better developers. Instead they should learn about design principles, and instead of thinking "which pattern should I apply here", they should be thinking, "what is the best way to create this code so that the basic design principles are upheld". You can start with SOLID principles and go from there. The same happens with language features; when generics were introduced, everyone wanted a generic class for some reason when it's almost never needed outside of the Collections framework (bit of a sweeping statement but I hope you see what I mean). In fairness, I don't think it's really Java's fault, only that it's been around long enough for there to be many more examples of this kind of thing. I've been working in Java for 15 years and C# as my day job for the last 3 - you can easily pick out examples in C# where the langauge has been abused: dreadful LINQ expressions where a simple for-loop would suffice (and be quicker), or multiple Events added to a class, ALL of which need to be hooked up by calling classes for it to be usable, so an Observer really would, actually, have been a better solution. I've played around with functional programming and there are a lot of claims around how it forces programmers to write better code. I'm not sure how it's going to stop programmers abusing language features or the language characteristics, though. I may well be wrong about that and am happy to be put right by a knowledgable FP dude.

dmacvicar 12y ago

While I have seen what you describe, I am not sure if it is only specific to Java, and I have to admit that I enjoy working with the Java platform. There are things in the ecosystem that annoy me more. We use Java in a non-standard environment: products built on a enterprise Linux distribution, and therefore built using the same infrastructure and conventions: everything is built from source as a dependency chain, so that you can patch it and provide support, and ship those patched components back as packages. Everything is built in a repeatable environment, jailed in a VM, no network, that only contains the dependencies you declared. So there were those nice times where building a Java library meant packaging 2 or 3 dependencies, then packaging the library was as simple as unpacking, apply any patches, set the classpath to the dependencies and run ant. Then install the resulting jar. It played well with the environment. Java build tools are insane. To build most libraries I now need Maven. Maven needs like a hundred dependencies to build, plus some plugins that need those dependencies, and those plugins build with Maven, the dependencies too. At the end, to build Maven, you need to have all components which are the reason you are building Maven in the first place. So this makes me thing Java developers don't think in terms of layers, and they pull dependencies without balancing the costs (writing one function vs depending on 20 more jars). A build tool should have almost no dependencies outside of the base system (in this case the JDK) and the compiler. But no, they added even a Dependency Injection container. And now they realized that the one from Google is better, so they switch to it, but without removing the old. So now they may be depend on 150 packages instead of 100. Great. Lets add more stuff. Imagine if to build make you need to have Gtk, and a library that builds with cmake and another library that builds with scons. And all the noise with this advanced nuclear engines and frameworks to power something as simple as a build tools is at the end useless. At some point the project still declares technical bankruptcy and dies. Java has a lot of "choice" in terms of libraries, but a good percentage of them are dead projects.

mike_hearn 12y ago
Are you really generalising to an entire industry from the build procedure for a build tool? Why are you even building Maven in the first place? My experience with Maven has been: 1) Download and unzip 2) Run it and that's all that was necessary. Meanwhile on the fly dependency resolution is very nice and a feature of most modern platforms.

arel 12y ago

As the author said its not the languages fault. And if you know what you are doing then Java is clean, mature, performant, dare I say it enjoyable platform to use. I think there also a generational conflict here. Java is a development environment that was born in the big architecture and 'development as enginerring' era of the late 90s. Spring was a reaction to the over engineered J2EE and now even Spring, the early liberator is considered over engineered. Its our dad's language. There is still a certain mindset from that era that was conditioned by the GOF and Universities and amaeteurs churning out developers but it is increasingly rare. In fact I find Java is amongst the most interally introspective and disciplined in terms of coding taste and style. I can almost guarantee if I look at another Java developers codebase that I can follow their code structure and style without too much effort. I'm not sure that would be the case for the large amount of very individualistic FP code being generated currently.

pjmlp 12y ago

Java is not the problem, enterprise architects are. If anything, Java allowed the so called architects a much easier path to such crazy skyscrapper designs than any enterprise language before it. So of course they went crazy with Java, and later on C#, because it was so easy to do so, without being caught in core dumps and similar issues. Anyone complaining about enterprise Java, just needs to go back a few decades to see what was being done in C, C++ with CORBA/DCOM, VB/Delphi, CLIPPER and tons of wannabe 4GL languages. Any language that wins the hearts of enterprise architects will suffer the same pains that Java is known for. I can already imagine a "Enterprise Functional Design Patterns" and similar books.

mike_hearn 12y ago
Ah yes, DCOM. That was truly the domain of the C++ enterprise architect! Today's AbstractProxyFactoryBean was yesterday's IDispatchProxy, IRPCProxyBuffer and so on. What's scary is that big chunks of heavy industry are all standardised on it via OLE for Process Control (OPC).
- pjmlp 12y ago
  Thanks to WinRT is it back!
revscat 12y ago
> I cannot agree more. At this moment I have an interface open with the following signature: public interface ClientBenefitOrder extends Internationalizable<ClientBenefitOrderDisplay>, CBMEntity, Enableable<OfferCategories>, Deletable, Comparable<ClientBenefitOrder>, ClientOwned This is entire application suffers from Enterprise Architechtitus, and like OP I have encountered that far too often for it to be a simple mistake. There is a cultural tendency in Java land towards overengineered solutions. It's pervasive. It also makes for bad code.

zmmmmm 12y ago

It will be interesting to see if Java8 inspires a fresh look at the design approaches used in the Java world. So many of those over-architected Java designs are trying to solve lack of flexibility and expressiveness in the language. There's an opportunity now to keep the good and move on from the bad ... it's terribly unfortunate though that it's not clear if Android will ever properly update from Java6 syntax. If it doesn't a large amount of the Java ecosystem is never going to move on from there.

frugalmail 12y ago

I'd much rather have a large application written in OO w/ Java then a functional only application. I have serious concerns about maintainability otherwise. This is of course assuming that we have good developers on either side. Especially when the language in question is getting libraries and native features that pull in the good parts of other languages. Blog posts like these make stupid generalizations. I'd also like to say if 5% of the Java Developers are the good developers that would be factors more than 100% of the Clojure developers + 100% of the Haskell developers + 100% more than the F# developers.

kasey_junk 12y ago

Wow there is a lot of bashing of the GoF patterns going on here. It seems like lots of people have a misconception about what patterns are. Patterns aren't a goal to meet with your software. They are common emergent solutions to standard design problems. The GoF didn't invent them, they just cataloged and provided a standard name for them. So once we have a common name, shouldn't we use it? If I see a FooFactory, I have a pretty good idea what to expect in that class. So the problem with a FooFactoryFactoryAdaptor isn't that it is following GoF patterns or in it's silly name, it's that you have a solution that has at least 3 levels of abstraction. The patterns didn't cause that.

CmonDev 12y ago

You can use Xamarin (C#, F#) for Android though, which will let you go multi-platform in future.

oldmanjay 12y ago

well nothing convinces me like unsupported assertions and undirected insults. I now hate java as well.

louischatriot 12y ago

Interesting read, explains well why I don't like to code in Java anymore. Most Java devs who go too deep in frameworks and complexity should try to build a small project in a very dynamic and concise tech. I always recommend Node.js for that, since you have to selcet the right module for every job, have to think it through and really understand what's going on, and can easily step inside the code if need be.

pramalin 12y ago

I think the author is out of touch with modern Java development practices. Any decent Java developer would have got exposed to POJO based development[1] by now. [1]Expert One-on-One J2EE Development without EJB - Rod Johnson, 2004 These days even the much hatted EJBs are POJO based and lot easier to work with. Not to mention Lambda support in Java 8 and the hybrid approach of Scala, my favorite.

jeremyjh 12y ago
I think the commentator should read the article. The author does not once mention EJB. The problems he describes are endemic to all kinds of libraries and frameworks and are VERY much a part of most shop's interpretation of "modern" Java development.

jaxytee 12y ago

For Android developers interested in building apps in Scala check out Scaloid: https://github.com/pocorall/scaloid https://github.com/pocorall/scaloid.

larsmak 12y ago

I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, android, etc. I've used lots of frameworks like Spring and Hibernate. Although such frameworks often provides abstractions and encourages usage of design patterns, I've never really found my-self getting lost in their layers of abstraction, and I've can't really say I've come across any "AbstractAdapterFactoryProviderBean"-either. I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past. When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.

lnanek2 12y ago
I can say the same re your experience, but I kind of experience the same thing he links to with Gradle and really despise it. Handling the constant Groovy errors and Gradle errors, and spending my life digging through their docs for a language and a build system I couldn't care less about really depresses me when I'm a Java expert. Give me a stack trace and I'll have the problem fixed in five minutes with unit tests and UI automation tests done later that day. But give me a gradle error and I'm stuck in their docs all day, you might have a solution this week. And by the way it breaks automatically all the time as Android Studio and the android tools plugins and all the rest version up. I wish we could have just stuck with Ant and Eclipse for Android, which are known evils. Instead every update of Studio and Gradle someone on the team has to draw the short straw and try, then either give everyone else the OK or tell them to stay the hell away from that version.

hawleyal 12y ago

I second and third everything he said.

virmundi 12y ago

Having worked in the Java world for the past 8 years, I think the issue with the developers is that the work is boring and they want to solve some problem. Folk who work with Ruby (at least 2-3 years ago) were doing something interesting. It could be a simple CRUD app, but Ruby made it interesting. People wanted to be there. Java is not. Instead, Java has a history of patterns for the sake of interest. Need to inject something in? Use a FactoryFactory. Most of what Java becomes revolves around having to do tedious CRUD apps for the enterprise that constantly change what they want.

sigmaml 12y ago

> More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit. It is sad to see such strongly-worded blanket statements. The author generalises his experiences with Java to entire OO. He doesn't, unfortunately, seem to realise that non-Java OO does exist. Also, several lean Java frameworks exist, without deep class hierarchies and factories of factories. Finally, OO is one of several possible ways to modularise and scale code and teams. FP is another. As languages like Scala have been demonstrating, it is possible to selectively blend features of both in fruitful ways.

robmccoll 12y ago

So happy to read this, yes, yes, and yes. Another big problem with Java to me is that the standard library and available frameworks are so massive, that there are thousands of ways to solve any given problem. This is bad, because only a handful of the solutions perform well, result in readable well-written code, and are efficient (from both a productivity perspective and resource utilization perspective). I'm not sure why, but it seems like many developers are almost trained to pick the bad ones. Perhaps the high level of abstraction enables the programmer to ignore the realities of the implementation?

bmoresbest55 12y ago

As a newly hired Java dev I can understand the problems that Java has with many levels of unnecessary complexity. However, I do not think it is right to simply say that all or even most Java devs are bad. First of all the definition of bad is relative to the person and secondly I would not agree in saying that they are all or mostly bad. People are usually trying to do the right thing and if that does not fit inside your ideals then it is bad? I guess all I am saying is not the throw stones. No one is perfect and to bash a whole community today based a snapshot of what you have seen is narrow-minded, look for the good parts and focus on those at least. Teach someone to code well in Java, if you feel so inclined to say that you know better. I know that there is a lot to learn, personally. I currently do like Javascript and Python as well but I would never look down on Javascript, Python, or Java communities. They are all great in their own way and in many similar ways. We all enjoy coding at some level, why does anotehr way of doing that have to be so worng?

cromwellian 12y ago

I think most of the problems are caused by enterprise, enterprise frameworks, and the sheer age of Java. There's a lot of technical debt built up and a lot of enterprisey frameworks that are way over engineered. I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc. I think the article is right in one important aspect: the way Sun built Java was to pretend as if everything should be a competitive market. So pluggable drivers for everything. Rather than build in say, one XML parser, instead let's build in a whole system to allow you to plug in any XML parser. As a result, it takes 4 lines of code to do what should work in 1 line. On other platforms, Python, Ruby, Go, et al, there is no such assumption that one needs an abstract interface to allow multiple implementation providers. You have an opinionated built-in implementation, or you use third party APIs. This is why you have stuff like DocumentBuilderFactory/DocumentBuilder/etc. When really, you want to write: Document doc = XML.parse(...) Enterprise developers copied the basic design of having provider lookup/locators. This is why we have AbstractFactoryLocatorServiceLocator stuff. Where I part company with the author is the total trashing of OO and the language. There are certainly lots of warts and things to complain about, but I haven't used a single language where I didn't have a boatload of things to bitch about. I think you fall in love and there's a honey moon period with most languages, and then the beer goggles wear off after daily use and you see all the flaws.

josho 12y ago
You are bang on. It reminds me of the opposite take that we've seen in browsers as of late. Eg. innovate with webkit specific extensions then standardize what works. Java meanwhile standardized conceptually useful concepts (Swing, Java Server Faces, etc), but the markets for pluggable Swing or JSF components never took off. I think it's that under Sun's direction the intent was to create markets, e.g. a market for GUI components or web components, a market for server components (EJBs). At least in the case of server components, Sun made a lot of money by licensing J2EE servers. I suppose that was their motivation all along for forcing DocumentBuilderFactory's on developers.
tootie 12y ago
Java is not designed to solve programming problems, it's designed to solve organizational problems. And it does a pretty good job. That's why you see lean startups shunning it then slowly migrating when their company gets too big.

uptownJimmy 12y ago

Recently-graduated student here, middle-aged and with more than my fair share of life challenges under my belt. I fell in love with coding by accident, after half a life in the restaurant trenches. But one of the things you can learn in the trenches is the value of patterns, and the value of recognizing patterns. Over the years I've come to trust my instinct for recognizing patterns, hard-won as it was. Java is swamped in an over-proliferation of verbiage. That is the first impression one has of the language in school: that it requires twice as much code to do anything. And that was, as well, my last impression, as they tried to prepare us for our entry into the world of enterprise computing by steeping us in a rolling, boiling stew of jEverything. Too many cutesy names in a programming language just felt WRONG, and I think my instincts have been borne out. Java is a mess to behold and to work in, and I am fantastically glad that I didn't get that first (Java) job I applied for, but instead got the second (ASP.NET) job. Irony abounds, I know, but .NET seems streamlined and elegant compared to Java EE. Turns out, sometimes you actually CAN judge a book by its cover. And by the 1496 pages in that Java textbook, which, hysterically, serves as merely an introduction... I don't know where I'll be in a few years, but I'm fairly certain I'll not be coding in Java.

lkrubner 12y ago

Java combines OO with strict typing (unlike Ruby which has OO without the strict typing). As such, that particular combination leads to bloat and verboseness. See: What did Rich Hickey mean when he said, “All that specificity kills your reuse!” http://programmers.stackexchange.com/questions/199217/what-did-rich-hickey-mean-when-he-said-all-that-specificity-of-interfaces-cla http://programmers.stackexchange.com/questions/199217/what-d... Part of the answer given: "If you have two entities { "name":"John" } of type Person, and { "name": "Rover" } of type Dog, in Java-land they probably cannot interoperate unless they share a common interface or ancestor (like Mammal, which means writing more code). So the interfaces/types here are "killing your reuse": even though Person and Dog look the same, one cannot be used interchangeably with the other, unless you write additional code to support that. Note Hickey also jokes about projects in Java needing lots of classes ("Who here has written a Java application using just 20 classes?"), which seems one consequence of the above."

frowaway001 12y ago
> Java combines OO with strict typing [...] > As such, that particular combination leads to bloat and verboseness. It's bloated and verbose, because Java isn't very good at it, not because it's a fundamental issue of OO with types. > in Java-land they probably cannot interoperate [...] Ditto.

mark_l_watson 12y ago

I agree with the general sentiment of the article. I have used Java since the beginning and I have written many books using Java for the examples in the books. I mostly use Haskell and Clojure (with little text utilities in Ruby) now, but I still do find that Java is sometimes the best language for some projects. Off topic, but Java 8 streams and inline functions made the language better. That said, I no longer use Java in any sort of "standard" way. I stopped using getters/setters years ago in favor of public instance variables. I also write a lot of static methods ("functions"). Basically, I try to make my Java code as concise as possible. I also have turned my back on large server side frameworks. For web services, embedded Jetty and a JSON library is often all the library support that I need.

critium 12y ago

I actually have a different problem. Java developers that are IDE jocks and dont have any kind of understanding of what is happening underneath the API. Take these guys outside of the IDE and they dont even know how to compile the code.

kyllo 12y ago

The language has some very poor design decisions baked into it (read: no functions) but the biggest problem with Java is that it's the lowest common denominator enterprise programming language, and managers have used it to lower the bar in their attempt to commoditize programmers. As a result there are lots of Java programmers on the market, with low salary expectations, and the code they produce is of commensurately low quality. As Paul Graham put it, Java is a language you learn to get a job. Do you want all your company's code to be written in a language that your programmers only learned because they needed a job?

zkanda 12y ago

I heard Kivy is getting more popular, that is if you like writing in Python.

kaonashi 12y ago

The dependency-injected style is great for mitigating side-effects and avoiding hard dependencies in code. The problem is that it's a poor substitute for currying and composition.

_pmf_ 12y ago
I agree.It's good design in the disgusting veneer Java requires.

michaelochurch 12y ago

One problem with Java is the 15+ years of bad taste. Design patterns are "revenge of the not-nerds". It's "I don't know what a monad is and don't care to learn, but I'm going to make you feel the way I do when I see math by renaming the sine function to VibratorVisitorFactory." Moreover, Big Software is generally a bad idea. There are occasions where large programs are a good idea, but the default should be small, composable units. Scripting and batch jobs aren't "baby coding". They should be the default unless you need a long-running server process. Most programs (over 90%) should be doing one thing and doing it well. The problem is that people don't code this way because it's better for enterprise managers' and architects' careers to say they oversaw gigantic, overarching software projects. I've actually noticed that data scientists, while their line-by-line coding skills aren't as good as a professional software engineer's, are usually much better designers (and far better communicators) than Java engineers. Sure, R is janky and Python has ugly corner cases, but data scientists write programs to do specific tasks and generally are good at keeping code small (because they have a personal responsibility for the code-- if they can't read it, it's basically lost-- not experienced by "architects" who can hire maintenance engineers to clean up their messes). You don't see the enterprise "software for software's sake" problem. The result of Big Software tends to be Java Shop Politics, as described here: http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/ http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol... . It's not the fault of Java. It's just a bad way of writing software.

thecage411 12y ago
I've noticed that the combination of math and communication skills is pretty well correlated with producing clean designs and code. Data scientists probably have those skills more often than programmers, but I'd argue that it's the skills rather than the culture that account for the difference you are seeing.

jdennaho 12y ago

I've worked with java for 10 years now... I have seen some shit let me tell you.

curtis17 12y ago

I totally agree with the original poster. I picked up Java in the mid-90's for server-side dev. Grew to loathe it. When Google announced an open-source OS for mobile - I was so happy. But ... Java. Broke my heart. Don't Google have any taste. At least Google could bless an alt-Java Swift-ish alternative like Kotlin, Xtend, AnythingButJava.

mike_hearn 12y ago
They don't really need to bless it, do they? Any JVM language that targets Java 6 should work.
- curtis17 12y ago
  Google have issues with Oracle. Why not bless an alt-Java and give developers a clear signal. The end game should be Kotlin or Xtend or ? -> Dalvik/ART. Cut out Java.
  - wstrange 12y ago
    Dart for the win
    - curtis17 12y ago
      Dart is interesting but a little too Jave-ery in both syntax and tools - Dart Editor is Eclipse based. Also, not sure how committed Google is long-term. Google's issue is too many languages and runtimes: Go, JS/ES6/V8, Dart/DartVM, Java/ART, PaNcl, RenderScript. With the Material/Paper UI Google have given dev's a consistent, elegant unified surface. But Google should also be moving in the direction of an (elegant) unification under the hood. Java and JS are 20 years old - but are at the core of Google's platforms - Android and Chrome/OS. But what - Kotlin, Dart, ES6/7?

kizer 12y ago

As a relatively young programmer, I feel that I'm just now exiting this stage of over-abstraction and pursuing a "perfect" design. Perhaps it does plague many older programmers, but to me super object oriented programming was a sort of programming puberty. In high school, I would sit down to write a Java program and figure that I would have to construct this grand architecture where each class reused absolutely no code and fit perfectly in an abstraction hierarchy. Of course, I would quickly lose focus of business logic and write a gazillion SomethingSomethingRepresentation classes and get nowhere. It really hit me when I realized I had a file named Null.java :)

talles 12y ago

> "(...) OO is actually pretty shit (...)" Relief washes over me in an awesome wave when I read this line. No, no, I'm not attempt to mindlessly bash OO. But I've worked over the years with folks that put OO as some sort of holy rules. When arguing X vs. Y the discussion goes well until someone says "Y is wrong, Y violate {this} of OO", shit, when that little statement is made I know I'm lost. Because even if I attempt to show that in this particular case violating such principle is good, I am doomed to be considered a heretic, an outsider, and sometimes automatically a bad programmer. I've tried to not thought of my self as an 'enlightened', but people kept acting as believers of such religion over and over that I could help myself sometimes. It's pretty much the feeling of being a philosopher teacher in mormon cult of something.

JAlexoid 12y ago

"Android - really the biggest reason today why anyone besides the enterprise guys cares about Java anymore" This line just says - ignorance. Thee is a *tonne of stuff in Java. And just because the majority of developers are low quality(what language does not have that?), does not diminish the interesting stuff that is going on with the whole platform.

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

maxwin 12y ago

"I’m an Android developer, stuck using Java. It’s breaking my heart." Glad that I am not alone.

curtis17 12y ago
Definitely not alone. At the Google IO Android Fireside Chat, a developer asked the Android team about using an alternative to Java for development - Scala in his case. Pretty much 'no' was the response. But don't Google have any taste. Kotlin or Xtend imo are lighter than Scala and would be good fits for Android.

rbanffy 12y ago

Not only Java. I die a little every time I see a PHP application trying to cargo-cult common Java overdesign patterns because "that's how 'Enterprise' apps are built".

peterashford 12y ago

I have been using Java for a really long time. I have never seen a "AbstractAdapterFactory" anywhere. Ever. Disclaimer: never did any J2EE BS.

lukaseder 12y ago

As the article states, this isn't a general Java problem. Just a problem of people copy pasting horrible code suggestions (or design suggestions) off some vendor's tutorials. Here's a blog post that shows how to make a game out of that madness we have gotten used to thanks to JEE / Spring http://blog.jooq.org/2014/04/01/spring-api-bingo/ http://blog.jooq.org/2014/04/01/spring-api-bingo/