Java is just fine for your online service startup development
pietro.open-lab.com
pietro.open-lab.com
On a side-note, I will say this - I am a Java developer (at my day job), and Java-land boasts some of the best tool support there is out there. On the flip side, the refactoring argument does not hold much water. These days almost everything in Java, especially when using any kind of framework means a lot of configuration and wiring using XML, Annotations and other syntaxes (EL - Expression Language comes to mind). Most tools don't see these as live code, so refactoring essentially boils down to a lot of text search and replace.
Java-land is learning a lot from the other communities and products out there. I have been told the Play Framework (http://www.playframework.org/) has some potential but haven't looked at it yet.
When you want to radically change the architecture, as it happens when you've got the business/workflow model wrong, these refactoring tools won't help you.
My opinion about Java ... the JVM and the available tools kick ass, but the language is a PITA and this shows in the design of many Java-libraries. Things like PlayFramework are a wonder and it takes discipline and perseverance to build things like that (not to mention having the will to break every best practice set out by the community).
But if your toolbox is bigger to begin with, I see very little advantages in using Java and his arguments aren't persuading: Java is a memory hog (which matters more than CPU cycles in the era of VPS), Java starts slow - it won't allow fluid workflows like Python/Ruby do. Java doesn't interface well with UNIX or anybody else for that matter.
Java-centric libraries and frameworks, while numerous, are tedious to work with: they tend to be over-engineered, overly-relying on XML to an unhealthy degree, hard to navigate and verbose to use.
I am coming from Microsoft/.NET and Ruby/Rails background and even after a year of adjusting, everything in JVM-centric world feels overly complex, slow and "rigid". Java people seem to swim in their own definition of object oriented programming and oh my... they stick with it. Even interviewing "Java-minded" people is painful.
All in all, I am 100% with the anonymous poster he quoted in the beginning of his post: "Its great for consultants because it means more billable hours" Not in a sense that it takes a lot of typing, but simply because there're lots of excuses to bill more for.
Tomcat with a simple app installed uses about 60 MB when it's idle and not much more with dozens of parallel requests. With Rails you need about 40 MB per instance for a very simple application.
Edit: And Java is lightning fast. An old project of mine running on a tomcat on a crappy VPS with 192 MB RAM serves the home page in about 100 ms, and without any manual caching, although it executes 7 queries to a postgres-db.
A simple rails app which I deployed on a VPS with twice as much RAM takes at least ten times as long to deliver the home page. And the only "dynamic" thing that happens on the home page is the formatting of a date. There is no database involved.
But the point is: If you add additional stuff, the larger part of the memory footprint of that additional stuff is only added once, because you don't need a new Tomcat for every request which you process in parallel, but only a very lightweight thread.
(Where "loaded up" equals a lot more than Rails/Django/etc gives you out of the box. We have a separate Tomcat running with a Solr instance for search, but that's for deployment reasons. If we put that in the same Tomcat I might push the RAM up to 192M, but it would probably be fine as it is)
JVM is fine if you're running only a single instance of it: just use threads instead of processes. The problem with JVM is that you often can't afford to have several of them running: in Java world everything is measured in hundreds of megabytes, that's the smallest unit of measurement they use (often supplemented with references to 32GB servers, "they're so cheap now"). Check out Batik Java library for rendering SVG. A single 45Kb SVG file, when fully parsed, eats up 150MB right here on my laptop. After serveral repeated test runs, JVM memory usage grew to a sweet 540MB, where it stopped because I capped it there via -Xmx. For comparison: Inkscape, which is an entire SVG IDE powerhouse, not just a parser, consumes only 3MB more when I open the same file in it, so that's like 50x less, plus it doesn't grow.
See, unlike CLR or Python/Perl/Ruby, JVM truly is a virtual computer, i.e. running a WAR file under Tomcat is kind of like running an Office 2008 inside of an invisible VMWare image with Windows pre-configured to occupy either 500MB or 1GB or comparable number. I just don't get why Java people are so damn proud of it. Moreover, they find nothing strange about this bizarre arrangement because they're completely absorbed by that JVM instance.
To demonstrate why Java doesn't belong on UNIX I invite you to implement find, grep, less and sort as Java programs, pipe them all together in a bash console and enjoy the show. :-)
In the end, there is nothing with Java that can't be dealt with by paying a few extra $ for hosting. The main issue is that JVM is an OS, a much more corporate, boring, uptight and over-engineered (and much less fun) than UNIX is.
I also want to address some of Tobias42 comments: for the most part I absolutely agree with him, except I don't follow his comparisons to Rails: we are comparing platforms here, not languages or frameworks. JVM is a memory hog compared to UNIX, and if he wants to compare Rails, I'd recommend loading his Rails app into JVM via JRuby/Tomcat and seeing what happens to his 192MB VPS box. Moreover, I wouldn't call 100ms/page (i.e. just 10 requests/second) "lightning fast", which makes his next comment about "Rails taking 10x longer" sound a bit strange: how hard does one need to try to build a web application with 1 request/second performance?
A Java web application however needs very little additional memory per request-handling thread, which makes its memory footprint much smaller when many parallel requests are involved.
100 ms for the home page in my Java app might not be great but, considering that 7 separate queries to the database are involved and that it runs on a very weak server, I think it is quite decent. And because of the use of concurrency (threading) there is a good chance that 100 ms for a single request translates into more than 10 requests per second. But I still wouldn't call my webapp lightning fast. I was calling java lighning fast because in my case I still get decent response times on bad hardware and with an inefficiently programmed application (7 db requests that could as well be cached and only refreshed every hour or so).
You are absolutely right about the rails app however. The 1 second response time is not normal. I just measured again and suddenly I get similar response times as for the java app. The server must have been under heavy load before (maybe the automatic backup). I admit that my quick measurements are not very representative and apparently not reproducible reliably, but still: about the same response time as the Tomcat with no database activity and on a faster server. I also checked a different rails project of mine running on an equivalent VPS. Pages where two simple database request are involved, which, when directly invoked in psql, take 15 ms, take 300-400 ms to load if not cached.
If a page takes 100ms, that doesn't mean you only have 10 requests/second. With a little care you can have thousands of requests per second, especially on top the JVM.
> A single 45Kb SVG file, when fully parsed, eats up 150MB right here on my laptop.
That's not the fault of the JVM, although I do agree that many Java-libraries are memory-hogs.
The only difference between the JVM and CLR/Python/Perl/Ruby is that the JVM doesn't return the used memory to the OS. This means that if the JVM reaches 1 GB of used memory, it will remain there even if the GC kicks. Also, when allocating memory, the JVM has to allocate more memory than it needs because it needs space to degragment the heap. But on the other hand compared to CPython / Ruby MRI / Perl ... the JVM's GC is generational and heap-compacting, making it much more efficient memory-wise for long-running processes ... allocation is cheaper, deallocation is smarter and you won't end-up with a heap that looks like swiss cheese.
Since learning Ruby, I've noticed that my attitude towards Java has taken a complete 180. It feels like doing anything in Java is like mowing your lawn with a pair of hand scissors. You can get the job done, but it takes a lot of extra steps/effort when compared to more powerful programming languages.
I don't think that the majority of people who are using something else besides Java to build their web app are doing so just because they read some Java-bashing statements on a website. They're either basing their technology choices on prior experience or are just picking something that appeals to them and rolling with that.
While it is definitely true that there is nothing in the nature of Java that forces you to use the kind of complex solutions often foisted on Java programmers, there definitely is something in the nature of Java that leads to needlessly complex code and heavyweight patterns that are not needed at all in more powerful languages.
To me this article just seems like a justification to use Java where none is needed. You can do a startup in any language, and the best one is the one your dev team is most proficient with. Java is the 500-lb gorilla these days and doesn't need any advocacy.
It's possible that English is not the OP's first language, but even with this in mind nothing in this article makes any sense.
Nothing in the language forces verboseness for the sake of verboseness.
"public static void" has zero chance of containing errors. If you make a typo, it won't compile. It's not code, it's just "stuff". It doesn't translate to code. It doesn't "do" anything.
If you really can't learn to look past the "stuff" into the code, get your editor to hide it from you if you must.
Using "public static void" as an argument is almost as ridiculous as people who cite the lines of code needed to program HelloWorld.
Verbosity in a language should be measured in terms of actual code that does stuff. Not characters in source code.
For example, would you consider Basic with line numbers to be a verbose language since it has a number at the start of each line? Well no, because those numbers aren't code.
Another example:
Regexps are extremely terse and compact. Would you rather debug regexps, or java code? Which is easier to work with? Is it easier to make a mistake and introduce a bug in a regexp, or in java code?
The argument that less lines/characters = less bugs is not a good one.
It is verbosity. It's less harmful than some other instances because as you note it's extremely unlikely to cause bugs, but it's still noise that detracts from readability by obscuring the code that's actually relevant to the task at hand.
Would you rather debug regexps, or java code? Which is easier to work with?
If the regexp is expressing a concept that would otherwise take 20 lines of ad-hoc string processing in Java, I'll take the regexp.
If I'm looking at code, the "public static void" doesn't detract from readability at all. I would much rather see "public static void" than some new 'less verbose' &$%||foo|| stuff I have to look up. I find it much easier to read words than characters.
It's a wonder anything works in some of these new 'unverbose' languages, where a 'concept' is a single character, and a single char typo can mean you've suddenly got a bug you have to go find.
Verbose:
1 : containing more words than necessary
: wordy <a verbose reply>; also
: impaired by wordiness <a verbose style>
2 : given to wordiness <a verbose orator>
If you want to argue that there are good kinds of verbosity and bad kinds that's fine, but don't try to make up your own definition and expect anyone to buy it.
I agree though, it's perhaps not the best word to use.
Use what you enjoy using though. But please don't buy the FUD about verbosity.
You don't regexp's compact syntax. That's fine. You would have a point if you say that its more readable, let's say:
1: EXACT <a>(3)
3: PLUS(15)
4: ANYOF[ab](0)
15: OPEN1(17)
17: EXACT <cd>(19)
19: CURLY {0,1}(23)
21: EXACT <s>(0)
23: CLOSE1(25)
25: END(0)
/a[ab]+(cds?)/
but it's much easier to introduce a bug in 20 lines of Java code that deals with an ad-hoc parsing than in a regexp, specially if you have to change the pattern.
Verbosity is a bad thing, because it can cause bugs etc. But that's not what Java is.
"private static void" is just boilerplate. It's stuff you type to get what you want, but it can't really be considered verbosity.
Mine:
Not verbose:
puts "Hello, world"
public class Hello {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}The 'verbose' one, I read as ...println("Hello, world!")...
Perhaps I'm not normal, but I 'see' those code snippets to be identical in terms of code.
Lets face it, we're never going to be bound by typing speed, and as I say, there's no chance of getting a bug into that 'verbosity' in java. So the only real issue is down to taste, which is up to the individual.
Also, have you seen those studies that show that everyone has a number n, and every n lines, you make an error? If you're writing 3n lines in Java for every n lines you write in $LANGUAGE, you're making 3 times the errors.
Try and make an 'error' in the phrase 'public static void'. See how well it compiles if you mistype 'public' as 'pubic'.
If you're not able to read the code well, then that's one thing (Learn to read code better). But don't spread the misinformation about errors. And no. You're not writing 3 times as much code unless you're an idiot. LOC in Java is pretty much the same as LOC in python for example when written properly.
It's not that you'd make errors in typing, of course your compiler will check those. It's that code you don't write is bug-free, and every line you do write has a non-zero chance of containing a logic (not syntax) error...
But anyway, it's very easy to write 3x LOC in Java. If you don't write much smaller Python code, you don't know how to code in Python. I can't think of a single task (mind you, I'm a Rubyist, so I very well could be wrong) that would take less in Java, and even ones with identical LOC, you still have things like
BufferedReader myFile = new BufferedReader(new FileReader(argFilename));
myFile = open(argFilename)Mature language and tools, stable and "fast execution", clean interaction with popular services. Its not sexy but if you are competent enough - it can get the job done and get it done fast.
Takes at the very least a year to became proficient in any language, and spending that time learning about your tools, that's is a luxury a startup doesn't have. Wasn't it pure common sense?
Wouldn't the cost of learning a more productive (assuming the initial supposition is incorrect and that there is a difference of productivity between technologies) framework be diluted in the total lifetime of the product?
If all you have in your toolbox is a blunt axe, wouldn't it make sense to get a sharper one before you attack the forest?
In the end, it all depends on the lifetime of the product. If it's a one iteration release, then go with whatever you already know that solves the problem. If the lifetime of the product tends to infinity, go with the language that expresses the product in the most concise way and manage to learn it well. The vast gray area between these points is where you can place all those fancy languages and frameworks wherever your expertise and product dictate.
* Design Patterns (GoF + newer patterns) * OOAD/OOP * Refactoring * TDD, Agile, and XP * "Reusable", "Generalization", "Framework"
that Java developers read the topics lightly and apply immediately without taking the time to understand them and when to use them. This doesn't happen much in other programming language communities because I rarely see someone writing design pattern tutorial in Perl. I won't be surprised that we will see these issues again in Ruby...
although there are improvements, its still relevant
So it is in the past, boring, and in the past and boring. OK.