Hacker News new | ask | show | jobs
by strlen 5057 days ago
It's perfectly fine to use Java for this kind of software.

The hate against Java comes from using Java for application development: this is largely due to the kinds of applications that are typically written in Java (line of business software) and (this is the most important reason) accidental complexity and low quality of APIs like Spring or J2EE.

Recipe for programming happyness is to use the right tool for the job:

* Python (or Ruby) for web application development, development tools, and "devops" scripting.

* C (or C++) for pieces that need deterministic performance[1], provide a "native" feeling user interface, or require control over memory layout.

Note: performance and efficiency are relative to what your throughput and latency requirements are. Google's crawlers and indexers will remain in C++ for the foreseeable future, but (for example) crawlers for an intranet can get away with being in Java (or Python for that matter).

* Java (or Scala, Haskell, OCaml, Go, Erlang, or one of the many Lisps) for "userland" systems programming. If the majority of the system fits under the last bullet point, use C++.

* Avoid JNI or Swig if you can. Use JSON + REST for cross-language RPC. If you need performance guarantees of a tight binary protocol use Thrift or Protocol Buffers. If you have to use JNI, consider using JNA first.

* No matter what language you use, stick to high quality libraries and tools. For Java, you'll absolutely want to use guava, Guice, and either Netty (or NIO.2 if you are using Java 7) or Jetty + Jersey + Jackson (for REST APIs).

Pick up either emacs and cscope, netbeans, Eclipse, or IntelliJ for navigating a large Java codebase.

All Java build tools suck. Maven sucks less and is the de-facto standard in the open source community. Twitter's "pants" is also worth looking at.

* Don't touch Spring with a 60-foot pole: in the mildest terms it's unequivocal and absolute garbage. Ditto for any other buzzword you may see in a job listing for an "enterprise" Java development job (with 20 years of experience required, naturally).

[1] Java performance can be quite high, but a JIT-ted and garbage collected runtime implies a lack of determinism.

7 comments

This post reflects the conventional wisdom very accurately. It is informative and contains good advice.

However, I also think it is a biased caricature based on "common sense" that isn't all that well founded.

Most of these languages are entirely usable in areas far outside the prescribed areas you have given for them.

If you are working on a few domains like embedded or OS stuff, low-level graphics or signal processing - or you need to interact with a specific system that is pretty language-specific like Rails or iOS - then your options narrow a lot. A few tasks are just a little forced unless your level of comfort is very high (doing 1-minute shell script jobs in C++, for example).

But it would be very hard to overstate the degree of overlap, in 2012. It no longer usually makes sense to write things in ASM for speed, for example...

In the rare situations where your favorite higher-level language is somehow not good enough for a given project, it is rare that you cannot make a mongrel project which drops to another level just where necessary. If your language does not support this then it is broken in a generally important way.

If you are not really ready or willing to fill in gaps and just want to glue existing things together, that changes things slightly - then your primary consideration is not the language but the available libraries.

The major differences between languages are mostly matters of custom and ideology rather than niche suitability.

Can you give us some evidence why Spring is "unequivocal and absolute garbage"?
Well, for starters the whole idea of programming in XML. That and gems such as http://static.springsource.org/spring/docs/2.5.x/api/org/spr... or http://static.springsource.org/spring/docs/2.5.x/api/org/spr...

Of course I can't a priori prove that Spring is garbage, much like I can't a priori prove that it's better to be healthy and rich than to be poor and sick. It is a judgement call, but a judgement call that I believe I'm qualified to make, having worked with a large Spring codebase for 2.5 years.

You can ditch the xml almost entirely in spring 3, which I've been using for 2 years now. All you need is 50-100 boilerplate lines and the rest is annotations. I agree that 2.x was xml hell, but it is worlds better now.
I sense sarcasm, but 100 lines of xml in a 200,000 line web application is wonderful. And this xml is specifiying critical things like database connection and pool settings, transaction management, entity caching, and more. You are going to be configuring this stuff no matter what platform you use, and the simpler it is the better.
> All you need is 50-100 boilerplate lines

That answers "Why not Java?" perfectly ;)

Java is a verbose language, but it's still awesome for a large category of projects. Are you a rails guy? how about those 50-500 lines of boilerplate code in the config files? Same thing as the Spring config files. Does that lead me to say "Why not Rails?" No it doesn't!

Saying it politely as possible: don't be a hater.

The word "SimpleBeanFactoryAwareAspectInstanceFactory" reflects everything I hate about Java and it's intended approach to OOP.
Cool, you must hate Objective-C too. I've done initWithParamAAndParamBWithASideOfAnObsurdlyLongMethodName but that doesn't mean I hate Objective-C.
You doesn't use autocompletion? o_O But it's much much better as simple_bean and you have not clue what it do.
I've got an autocompletion feature up and running, but I'm usually not dependent from it. However, that wasn't my point. I wasn't complaining about long class names. That's just a bonus. I was complaining about the misuse/overuse of design patterns throughout the Java Standard Library as well as Swing.

See, design patterns are a thing that's nice to have but some of them are more like cheap hacks that have made it into an influential book rather than mandatory patterns. I'd go as far as claiming that some of these patterns are merely a way of hiding what's fundamentally broken about OOP in a language where it's the only paradigm and where it is strongly enforced - like Java.

I haven't used it for a few years, but I always found it funny that a project that was supposed to make Java application development easier and more agile than J2EE ended up being just as large, if not larger. Core Spring did a lot for dependency injection, which was a big shift in thought. However, for dependency management, I'd go with something like Guice today.
Spring was innovative in 2008. Now, Spring is overbloat, buggy (look at request-mapper) and have old, sensless integration to others modules, see spring-data for NoSQL, or try integrate last version of Velocity with last version of Spring.

And additionaly, all, what you can do with Spring, you can do with JEE.

I think collectively we should point out the specific Spring modules as opposed to say that "Spring is overbloat and buggy".

Some of Spring modules seem to be quite stable enough. Others, the newer modules, will take time to be more mature.

Spring's goal have always been to be the 'glue layer' of the Java standards. Of course, now they want to be the 'glue layer' of everything, including Spring-Data for NoSQL (Neo4J and co.).

Speaking of which, your last statement is partly correct if only Spring == Spring Core. There's no MVC (in the sense of ASP.NET MVC or Rails MVC) in JEE yet (yet because things might change in the future). JEE has 2-3 technology covering the "VC" options: JSP, Servlet, and JSF. None of these are similar to that of ASP.NET MVC or Rails MVC.

I pointed one module out - Spring-Velocity integration.

"Of course, now they want to be the 'glue layer' of everything, including Spring-Data for NoSQL (Neo4J and co.)."

Why do you need this? It's just Java and you can... just use it. Without glue.

"Speaking of which, your last statement is partly correct if only Spring == Spring Core. There's no MVC (in the sense of ASP.NET MVC or Rails MVC) in JEE yet (yet because things might change in the future). JEE has 2-3 technology covering the "VC" options: JSP, Servlet, and JSF. None of these are similar to that of ASP.NET MVC or Rails MVC."

What do you mean with MVC exactly? This is just buzz word. MVC Model 2 Architecture (and now you have Servlet 3) is good replacement for Spring MVC. JSR303 and JPA (or other) is good replacement for 'M' (and of cource, in Spring it's same way). We talk about Spring or Rails/ASP? And of course, here solutions in Play/Play2.

Really, you don't need Spring. It's 'Bug layer'.

You pointed one module, as an example that describes the whole Spring as one unified framework.

Spring consists of multiple modules that you absolutely _don't_ have to use. This is where, I think, you misunderstood Spring.

When it comes to the modules, i.e.: Spring Core, Spring Transaction, Spring-Data sub-modules, Spring eventually use the JDK and/or 3rd-party API (possibility, in the case of Neo4J etc). Yes, you can use JDBC, JTA, JPA, and Neo4J API directly. For sure. But Spring has always wanted to become an alternative to using them directly by providing more features and supposedly better programming experience.

This is what I meant by _glue_. You're absolutely correct: you can use those libraries directly without Spring. But if Spring modules provide me with better programming model, more features on top of barebone implementations, why would I not use Spring modules? This, again, something that you seem don't quite see from Spring.

Let's say MVC is a buzzword and start from there. If you look at ASP.NET MVC and Rails MVC, they provide a programming model where you have a request mapper/route that maps a request to a method in your controller.

MVC Model 2 architecture does not provide you with that. MVC Model 2 architecture provides you 1:1 mapping between a URL with Servlet. Which means if you do a simple CRUD a'la Resource, you can either have 1 Servlet per Resource that acts as a dispatcher for the CRUD operation via either query parameters or multiple Servlets. Again, if you choose to live with that, that's your choice.

Spring offers a better programming model than MVC Model 2 architecture and there are people out there that prefer it. Spring also offers WebFlow, a module on top of Spring-MVC that helps building Wizard or Shopping Chart that involves lifecycle/steps. Can you live without it? For sure. Roll your own.

That's one, second, in Rails MVC, you can set the content negotiation to send back either JSON, XML, or HTML. You can do this with JAX-RS but that is a separate "servlet" per-se. If you want your API to live in a different part of your systems, this is acceptable. But if you want all of the request comes from one entry-point, you have to work harder than that.

Calling Spring as a 'Bug Layer' reminds me of this article:

http://www.codinghorror.com/blog/2008/03/the-first-rule-of-p...

I can pick other module... for example key-value. Wich benefits I have with key-value module? I don't need "integration module" for this job. Compare http://static.springsource.org/spring-data/data-keyvalue/doc...

and

https://github.com/xetorthio/jedis/blob/master/src/test/java...

I don't see any benefit or better programming experience or more features on top.

Other modules? You mentioned:

Spring Security/Acegi - Java EE do the job also. Seamless integrated with EJB and other technologies.

Spring Transaction - also.

I mean I see no reason to use Spring or any glue.

"ASP.NET MVC and Rails MVC": this is not Spring vs. Java EE question. I like Django and Wicket and it's much better as Java EE and, of course, Spring.

Map to function or to class - doesn't matter. It's same. Spring is same MVCM2. Why I should prefer write tons of xml crap, if I can use powerful workflow engine like Activiti, AristaFlow or jBPM or others? :)

Yes, I was careful to say "J2EE" and not "JEE". WebBeans/CDI in Java EE 6 are quite decent. JSR 330 seems as if they just standardized on Guice. JSR 318 is quite good as well: I highly recommend using Jersey if you're building a REST API.
I wish HN had the ability to pin posts. This is great. Absolutely what I was going to write, so naturally I think it is brilliant ;)

The right tool for the job. Java has it's place and it just where strlen said it should be.

I've been highlighting stuff with Diggo these days...
Link to the comment as a bookmark.
Rigth tool for the right job is key here. I personally like to add Groovy to the devops list.
I think groovy is sensless language. You lost all Java benefits like checked exceptions, robust code... what is about debugging? And you is not faster developing with groovy. You developing faster if you ensure quality and not inline filters or other crap. If you like groovy, look at Python.
I've used it _alot_ especially for scripting. Really powerful support for quickly write dynamic code to run transformations, connect to db's, connect to mq's etc. It's easier to read than python (for me) and you can just drop a lib in groovy_home for support to whatever dbdriver (like oracle). Seriously give it a go, before you call it senseless. But you know, use what you know and what you can be effective with to solve a given problem.
You ensure quality by writing automated tests, not by the language you pick to write software in.

And for the record Groovy is awesome. I used to develop in it alot, but now do more Rails and JavaScript, and I miss it's power and simplicity.

You're wrong there. I use Java for most things but dive into Groovy when I want features like almost native XML handling (via XmlSlurper & MarkupBuilder). Having a joint Java + Groovy project is simple as it's all just bytecode to the IDE.
What does "userland" mean?
That's what normal applications are referred to as opposed to kernel-level code. So anything user-facing that does not need low-level system access.
Code that isn't part of the OS kernel.

http://en.wikipedia.org/wiki/User_space

Yes, but you can use Java (or Scala) where C++ was mentioned.
The rationale for the distinction is given: deterministic performance.
Spring is not garbage.
Why is it not garbage?