Ask HN: Why do big companies tend to only build with Java?

There are a plethora of reasons that the enterprise uses Java and many of them are really good reasons but the main reason now is inertia, so many enterprises and vendors are invested in Java that to divest of Java just does not have a good value proposition, given the fact that their has not been a major revolution in languages or run-times, no one has had the stomach to try to move off in a serious attempt.<p>To understand it we have to look at the history of when Java came about and what Java brought to the table. Most people think it was a more modern language that was what won but the reality is that was just icing. The real winner for Java taking over was the VM, at the time Unix was dominating the server space (in particular Solaris) but Microsoft has a through monopoly on the desktop. So here you had all of development on one OS and all of the runtimes on another, The promise of Java was that your developers could continue to develop on desktops while delivering to Server architecture, it was not always totally smooth but it did work and their in lies the revolution that Java brought. A common development platform across architectures. It seems so common today but at the time it was huge, it had the potential to save companies millions if not billions.<p>Fast forward to today and a big issue with the enterprise is labor, and lets face it trying to take the road less traveled can introduce unnecessary risk into the enterprise. If a company is not in the Vally the quest to find a Ruby or Python or Node.js developer can result in not finding a single candidate, this is far more risky than another month of development time to stay with Java. They are totally different concerns, a small scrappy start up, can afford to kick the bushes of local groups to find a guy playing around with Node.js, an enterprise has no systematic way of figuring out if the kid at the local users group is an expert at Node.js or has just been playing with it for 2 weeks. To me this is the biggest one, talent is available locally and even if it is not, the big vendors and even the recruiters can dig someone up fast. This alone mitigates a lot of risk from the organization.<p>Second most enterprise software is built with Java and has Java API's, SAP, Oracle, IBM and many of the other offerings these guys use are in Java. I like to poke a lot of fun at some of those systems but the reality is implemented correctly they can save a lot of money and time and unlike in a start-up where every penny counts in the enterprise vendor supported systems are considered a good thing. They allow the company to focus on their core business while leaving system development to a vendor.<p>Which brings me to my last point, there is a new revolution underway, and I do believe that in the near future the cost benefit analysis is going to be so great that the enterprise will not be able to ignore it, and that revolution is SaaS. For the same reason I just highlighted, (focusing on core competency), SaaS will be huge, now not only will the enterprise not have to concern itself with maintenance of custom systems, but they will be able to offload support as well as infrastructure. Getting out of the infrastructure game for the enterprise will be huge and may herald the end or Java's dominance.

You can do rapid development with Java--it's less a condemnation of the technology and more the process that happens in big companies.<p>I've worked on contract in large and small companies, and the amount of paperwork to go through in large companies is ASTOUNDING. For example, we once had to get a test account created in the test domain (not even production). It took 23 emails, 4 IT requests, and 6 hours to complete--and that was the "accelerated" path.<p>But bureaucracy is only part of it. The real reason it takes a company to build something so freaking long is testing. Not just test-driven development (that's crazy talk, by the way), we're talking testers. Lots of them. Now, I'm all for testing (yay testing), but companies go to the extreme. I've had more than one of my projects take three to four times as long to test as they took to develop. Sometimes you luck out and get really good testers, though, so then life is peachy.<p>But to answer your question about why companies use Java, it's because it's widely taught, and programmers are thought of as interchangeable pieces. They can bring over a ton of people from out of the country for cheap labor, or just hire a bunch of D+ CS students and put them in cubes and give them detailed specs and just let them go at it. There's no thought to it--they're cogs in a machine.<p>Also, sometimes technology choices are just at the whim of people higher up--they have a favorite technology and push that as "the way," even in situations where it doesn't quite fit. Such is life.<p>To sum up, companies are slow to develop because of overhead and bureaucracy, and they use things like Java because they want cheap programmers, not good ones.<p>Edit: I should clarify something that came off as really presumptuous and pompous. Java isn't a bad technology, per se, and there are plenty of great programmers who use it. My point was that Java developers are easy to find cheap, so that puts a vote in the win column for larger enterprises.<p>That being said, there are a lot of really good reasons to use Java, and if you know Java really well, you can put together a CMS as fast (if not faster) than somebody slinging PHP or Python or whatever their language of choice is.<p>My main goal was to address why enterprise development is often considered slow by startup standards, and what causes that. I know a few really great Java programmers in big enterprises, and I know they often get frustrated by the glacial pace of enterprise development.

Good threading support (no global interpreter lock or anything like that).<p>Very fast.<p>Unicode strings.<p>Some measure of type checking (probably appeals more to large, enterprisey projects). This also makes IDE autocomplete easier.<p>Lots of libraries.<p>Cross platform.<p>And yes, a large pool of developers.<p>Not too many languages can check off all those boxes, making Java a sweet spot for a lot of enterprise development. Probably not a good fit if you just want to throw together a CMS, though.

Most of these answers don't seem to be written by anyone actually involved in "enterprise" development.<p>Here are our simple reasons:<p>* The JVM is fast.<p>* The JVM can take proper advantage of multiple cores directly (no GIL).<p>* The JVM is efficient compared to other runtimes.<p>* Java is type-safe.<p>* There's a library for <i>everything</i>, and libraries are generally well-documented, unit-tested, and provide stable releases with binary/source-stable APIs.<p>* There are a number of alternative languages to choose from that can interoperate on the JVM (Scala, Clojure, JRuby, ...)<p>I've worked with plenty of JVM/Java-based projects that shipped quickly. There genuinely isn't anything else I would use server-side.

Statically typed languages are favoured when you're working on a team with 40 other developers and you want the idiotic changes being made 5 desks over to break before they check in, not after you've pulled their changes.<p>Autocomplete also makes life staggeringly easier, as do strong refactoring tools.<p>Not having to deal with memory management is also a big plus.<p>When you put those requirements together you end up with C#/Java. Which is why a fair number of places whack together UIs in C# and server side code in Java.

There are good answers throughout this thread but the thing I find a lot of people forget is support.<p>Startup founders and small businesses tend to have more talent available to them. When you have 4 guys with MIT degrees you can hack through problems so you don’t need support. But if you’re a big company you sometimes have to settle for the day laborer. The guy who can do the grunt work coding but who slams on the brakes when he runs into any kind of problem.<p>As someone running a shop with those type of workers you have a choice. Have them wait for one of the more senior people to help them or throw $300 at the problem and have them call support.<p>This doesn’t produce the most elegant code but most big companies aren’t interested in that anyway. If it works and crashes relatively rarely most corporations are fine with it.<p>Unrelated to that it should also be mentioned that companies like IBM and Microsoft market to non-IT execs where as open solutions don’t have marketing departments. There’s a reason they say “No one ever got fired buying Microsoft”

It's mostly an ecosystem thing. Large companies follow the lead of their vendors and Oracle/IBM/HP all push Java. There is a vast array of third party tools and software packages for doing boring enterprisey stuff like monitoring and integration. If you want to integrate or extend one of the big ERP or CRM systems that is mostly Java. At this point there are lots of people that can be hired with passable Java skills and most consulting outfits have large Java programs. Admittedly this is something of a positive feedback loop that got started because the big vendors stared it 15 years ago.<p>As for team delivery speed it is certainly possible to deliver quickly. The dynamic languages have definite advantages over Java. There is less XML/property/configuration stuff to manage for instance. But the Java frameworks are actively developed and they get better all of the time too. Delivery speed is mostly a team and organization thing. Large orgs can take forever to deliver the simplest of things. It can take forever for people to decide what they want. You might have to get permission from three different VPs. You may have to schedule a series of meetings to have a decision made and it can take a couple of weeks the find time when all stakeholders have open time on their calendars. You may be dependent upon cooperation and resources from another team that isn't really motivated to help you because they have their own stuff going on. So it's not really a technology problem, it's a management problem.

Java is entrenched for the same reason the Cobal on mainframes it won the enterprise mindshare battle. By in large this has more to do with how these types of business function than anything else. Business work best if they have predictable cost based on revenue. So for custom software they need X amount of work then the business can hire Y developers. If a factory needs to make X more widgets it can hire Y more factory workers. There is a lot of evidence to point that software does not fit this pattern however this gets withing a few managers up the chain. Startups and valley companies handle this better because they focus on this at the core. I will make some points about the Java / JVM that I have found working with it for the last 14 years:<p>* The JVM is fast compared to VBScript type languages and slow compared to language that use C libraries (Python). There are benchmarks about how JVM is very fast at crunching numbers however in practice I have written very little code that is math I tend to use a library (math libraries written in C/Fortran). Most applications are moving bits around and are thus IO bound and so languages that can quickly be modified to use better caching or more complex data access algorithms will perform better. Enterprise web apps that use Java and are fast are the exception not the rule.<p>* JVM is a memory hog. Now this could be blamed on all the dependencies but even writing a very simple JSON web service is going to cost you a lot of memory. This makes compilation slow and development slow.<p>* Dependency management is a mess. Maven is helpful but is exceptionally slow with just a few dependencies.<p>* Multithreaded Java has never been as robust or fast as multiprocess applications I have see run in other languages. I have seen robust multiprocess Java applications but they tended to run per node because of memory usage and performance. I would say I am above average developer and have written and rewritten a good amount of thread code and the more I do the more I am convinced it is a horrible concurrency model for non super human developers.<p>PHP may make some inroads over time since it has a good base of people that can be hired. However I see it mostly to be used as an outsourcing tool when a project need to get done quickly. This is just my experience over the last 14 years so YMMV.

I think it's Oracle. It usually starts in the accounting department. Someone from Oracle calls them up and convinces them that they need to spend oodles of cash for a financial package, but that package requires an Oracle server. Now, they can't justify paying that huge price, so they tell the entire IT department that they're going to dump whatever database products they were using for most of the company departments, and switch to Oracle. Once that's established, the IT department staff learns that Oracle is a big pusher of Java, so all the coders have to switch to Java. Eventually they want to get a promotion, so they learn they can get Java certified and either catch a promotion or go to another big company with those skills.<p>When I was doing Java coding, guys would argue in boardrooms for months about design patterns and system architecture, looking fairly important to the boss, never really getting anything accomplished. I was so glad to switch all that to a forward-thinking company that used PHP and PostgreSQL -- we knocked out code really fast and spent less time arguing in boardrooms. Sure, we used design patterns, but we didn't get overly academic about it like the Java guys did.<p>Now, anyone trying to introduce PHP or PostgreSQL into a Java/Oracle shop would find it really hard. These guys want to keep their certifications relevant. The Java guys will say that PHP is a hack with the inconsistent parameters, and claim it's nothing more than juked up Perl. If they permit it at all, they'll call it a "template language" to be used only for the front-end. The Oracle guys will say that PostgreSQL isn't battle-tested enough like Oracle, lacks sufficient replication and migration tools, and tell you the tech support for it isn't as good as Oracle's. Then they'll scold you for considering PostgreSQL over MySQL since Oracle owns MySQL now. And when they go in that direction, they'll say, "Yeah, MySQL is great only for tiny stuff."<p>As for "rapid development teams using Java" -- LOL, that doesn't exist as far as I've seen in the Fortune 1000 companies I've worked in. Rapid, as in take 1 year to argue about the system design before you start coding it? Yeah, that's about how rapid it is.

Here we work with scrum and have a pretty agile development cycle. I really believe that if we were to develop our site ground-up, we would use JEE again for the same reasons some of you've pointed out... and actually, we're doing it!<p>But, for example, many of our webpages are made with PHP using some CMS (Typo3) because it's perfect for this. Our mobile site uses our Java webservices from PHP too.<p>I've been working with JEE (formerly J2EE) and JSE for some ten years and I know of Java's (platform and language) problems, but I think that they are surpassed by its capabilities, tools, resources availability, etc.<p>Do I want Java to go away? Why I ask? It works! It's not perfect, is not shiny, is not "agile", but it gives management that warm feeling of cash flowing in. Oh! And it gives me a job!

I have been doing Java for a long time, and while I personally prefer more modern languages I have found that <i>if I have to load up and work on someone else's code</i>, my life is much easier if it's in Java because the tooling (specifically refactoring support) is so good. So even if I inherit an old, awful, "big" codebase, I have a good chance of wrestling it into shape by pushing it around in Eclipse or IDEA, with some reasonable guarantees that I haven't broken anything along the way. So the fact that I'm not entirely doomed in this case (as I recently felt when I inherited 300k lines of very bad Python) is a good selling point.<p>So as a common-denominator for large codebases with average-quality developers it makes sense in the long term, although it's not terribly fun.

The success of rapid development is more a function of the team, than of the language used. It is wrong to blame Java for the failures of poor developer teams.<p>Java is stable, has plenty of libraries, lots of tools, is friendly to refactoring, testing, and it is not such a bad language. Just take a look at the tools developed in java by good teams (eclipse, apache, joss, spring and so on..)

History started it (it was the first or its kind), inertia kept it going.<p>When Java debuted, it was a Big Deal, and promised faster development, garbage collection, and multi-platform deployment to enterprises. As I see it, "enterprise" was (is) Java's primary customer. One they picked Java (likely more than a decade ago), there has to be a significant reason to change (remember, big companies tend to be risk-averse), and there hasn't been anything better enough to justify changes to the enterprise. Also, the big ERP systems use Java, so companies need embedded knowledge and consultant perpetuate the cycle. If you think getting them off of Java is hard, I worked for a company (a bit more than five years ago) where significant effort was spent getting them <i>to</i> Java, off of monolithic C.<p>As to your other question, yes, I know of very successful (multi-hundred MM (USD) revenue) that use Java in Agile teams. A company I'm starting to work with has several agile teams; some teams use scrum, some use kanban. So yes, they use it, and yes, it's successful.<p>Don't try to force your worldview too much on companies. As you get older, you'll find there are many good (and often several not-so-good) reasons for them being the way they are. they have the benefit of thousands of person-hours of experience. You (we) don't, yet.

Because Java is designed for projects that can scale up in size. Large php/python/ruby projects are nightmarish to maintain.<p>When you've got a project with dozens of teams and hundreds of components having things like static typing and well designed exception are really important to ensure data integrity.<p>There are also many features that languages like php lack, such as multithreading and atomic operations.

I also do believe it is the ecosystem. You wont find the amount and variety of tools for any other programming language. Just look for Enterprise Search Solutions (semantic, linguistic, etc.): the majority is written in Java.<p>How did the ecosystem grew so big? Java is free and is easier to learn and faster to develop, compared to other "big players" (e.g. C++)

Besides all the historical reasons cited, there's a simple reason: economics. The bulk of enterprise software are CRUD apps that maybe chat with an ESB or whatever; the quality is mediocre/ok, and whoever pays the bills just want to get the project done ASAP. The pool of Java devs is HUGE, it's quite easy to lose a Java dev and get him replaced the day after. The risk of using Java is very low from a management perspective; if you replace Java with Ruby/Scala/Python/etc the perceived risk would be much higher.<p>Besides, most big enterprises are already paying IBM/Oracle/Jboss/etc for Websphere/MQ/ or whatever App Server and support; it makes sense to use it anyway.<p>I would say it's mainly inertian and (perceived) risk management. BTW, I believe the Java camp got alot of things right, but that's another story.

The code we're writing today has an expected service life of ~15 years. Java code written according to current best practices will still run well, with minor maintenance, 15 years from now. Oracle and the JCP won't allow any changes that seriously break backward compatibility.

it's not just big companies that use java. We're a small company (15 ppl) and have built our backend in java and the frontend in PHP.<p>I'm not a developer but I think at least part of the reason for building in java is the abundance of libraries (i.e. Apache Commons). We also just do POJOs/Servlets so development can be rapid. I think most people think of J2EE when they think of big companies and java.

Because Java is strongly structured, it's easier to bulk hire and fire programmers into and out of large projects. The ramp-up time is shorter.<p>And that forced language structure can function as a rudimentary safety net for mediocre programmers.<p>From a large company's point of view, it is a cheap and homogenized programming force. You, I and Joel Spolsky might care about the "good" programmer that massively outperforms other programmers. Most businesses want cheap and reliability.<p>Add to that a market of off-shores and other workers that fit the "cheap" bill and you end up with dominance. When's the last time you saw a H1B that programmed in Haskell?

Many many reasons:<p>* Compatibility with installed base of existing code - Java is so prevalent on the server side that this is often a critical requirement<p>* Performance - The JVM is an amazing platform with excellent JIT compilation, very efficient garbage collection, great for concurrency etc.<p>* Huge library ecosystem, second to none. Most of the ecosystem is open source and if you choose your libraries and frameworks appropriately (i.e. anything but J2EE!) then you can be pretty much as agile as any other language.<p>* Major corporate backing (IBM, Oracle, Google, Red Hat). There's enough diversity in the supplier ecosystem that you don't need to worry about vendor lock-in too much (e.g. competing app servers).<p>* Java is more open and cross platform than the only credible alternative (.Net) - From a CIO perspective .Net is effectively vendor lock-in to a Microsoft stack.<p>* Great availability of "good enough" developers. There are also plenty of rockstars in the Java world if you look hard enough.<p>* Maintainable code. Java's relatively simple and concise syntax actually makes it quite easy to maintain with the medium-skill developers that most corporates have.<p>* It's not Java per se., but the innovation happening in the new JVM languages (especially Scala and Clojure) actually puts the JVM pretty right at the cutting edge of language development.<p>Note that a lot of the above reasons make Java a good choice for startup companies too, especially if you pick one of the new languages and go for "Java the platform" rather than "Java the language".

1) Corporations don't understand IT. To them it's a cost center, not an enabler. So to minimize costs they must find developers that are (a) easily replaceable (b) cheap to hire<p>2) Sun did a great job marketing Java in the late 90s and early 2000s. So corporate managers felt safe adopting Java; it was the "in" thing. And as kls said, corporations have a lot of inertia. Why break something when it's working? (It's due to this mentality that some corporations still run VB6 and COBOL apps)

It's a safe choice. It is easy to find Java developers with enterprise experience. There are lots of vendors and consultants with Java expertise. There is a lot of corporate mind share around Java. And at this point, most companies have a large investment in Java (or .net) so it makes sense to continue on that path.<p>"Taking months/years to get something off the ground" has little to do with Java itself and mostly to do with corporate project lifecycles.

I think it stems from the fact that you can almost always find a Java library for whatever enterprise product you're looking to work with. I have yet to find a major company (not a start up) that did not release some sort of Java API to its product. Just an observation and my experience, not rooted in any "scientific" study

Knowns. I think it's mostly because of the 'knowns'.<p>Removes some uncertainty around planning maintenance &#38; operational costs. Java developers are plentiful and framework training/certification programs are out there for the 'feel goods'.<p>Also... turns out, .NET is adopted for the above reasons as well.

Besides the advantages listed by others, Java make it easy for a team of developers to code together, not just at the same time, also across timeline. After you leave, the next guy coming in to maintain your code has a much easier time to understand the code. Big companies value that a lot.

I'm a Grails advocate, and can be pretty productive in it. This is coming from someone with 15 years of PHP experience (sprinkled with some other tech), and I'm pretty productive in that as well. There are some aspects of projects I'm actually more productive in Grails in, which is a byproduct of the groovy/java language syntax than anything else. GORM is a dream to work with for 90% of the projects I do, as opposed to <i>any</i> PHP-based ORM, for example, and even Rails' ActiveRecord. Obviously just "imo"<p>Probably a bit off topic, but PHP/Ruby/Python/Perl scale <i>up</i> much easier than Java scales <i>down</i>. And there's fewer large scale problems/apps than there are smaller scale stuff, so we see far more usage of PHP/etc in most day to day work.

I'm in South America, but I do work for a big company.<p>I believe that we use VB6 and .NET because that's one of the two main platforms student learn (the other being Java), and programmers can be treated as interchangeable pieces. You're certain to receive thousands of applications for a job posting, and get outsourcing cheaply and easily.<p>Are the results good? I believe they mostly aren't, not because of a flaw in the platforms. And yes, change is sloow. There are too many stakeholders for anything.<p>I've heard of agile development with Java or java-likes, and .NET as well, it's not a platform thing.

Its a well structured, well thought out language that somewhat feels like an extension of a lower level language, like C. Generally, companies working on big projects want developers who are comfortable with a wide variety of programming concepts, including using interfaces, modular code, etc and Java, and its ecosystem, helps to reinforce these types of practices. Static typing is also critical for a larger application, something like PHP is really just a scripting language for front-end display and if thats all you have used you are probably missing out on a lot of larger CS concepts

I believe that the structure of the language helps translating OO design to code. As OO is the preferred way of enterprises to describe their products (which may not always be the best way), they tend to think Java will make the product better.<p>I think Java right now is easily understandable by blue collars (not the code, but the architecture and the design part). It may not be the right choice, but big companies try to avoid the unknown and they tend to think that things they can understand (OO being an example) are better than the other options.

The only thing that's really wrong with Java is the language, and of that there are only 3 or 4 major things wrong with the language, most of which seem to have been addressed reasonably with scala.<p>The rest of the ecosystem is pretty good.

Java scales. You can be slow or fast in any language.<p>I'm a bit confused, you have experience with Java, or you don't?