

Java is just fine for your online service startup development - ppolsinelli
http://pietro.open-lab.com/2009/12/05/java-is-just-fine-for-your-online-service-startup-development/

======
raju
Good advice. If you know a technology well, then run with it. Focusing on
actually delivering value vs. bragging rights to the latest and greatest
dynamic language/framework.

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.

~~~
bad_user
About refactoring ... even if a project is pure-Java, the refactoring-tools
are too simple, boiling down to rename class/method/var, extract method/class
and things like that which are just too simple for real-world needs (and in
practice, kind of useless ... since I've been doing these same ops in dynamic
languages with a combination of find / grep / sed / emacs macros... with unit-
tests as guard).

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).

------
old-gregg
If you are a Java expert and know nothing else, roll with it: learning
something significantly different from scratch to a degree comparable with
your today's Java expertise will take a long time. That part he got right.

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.

~~~
Tobias42
> Java is a memory hog

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.

~~~
davidw
Honest question (I've never done Java web stuff): what does that 60MB actually
buy you? Rails gives you a whole lot of tools in that space.

~~~
old-gregg
It's hard to compare but Tomcat is functionally equivalent to something like
Passenger, Paster or Mongrel. And last time I looked, it actually ate 80MB. It
doesn't make sense to compare empty application servers: it is your running
application you should be concerned with.

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?

~~~
bad_user
> _100ms/page (i.e. just 10 requests/second)_

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.

------
dasil003
_And of course the point is that there is nothing in the nature of the
language and tools that forces you to use complex solutions._

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.

------
aarongough
"We should all be grateful to the dynamic language communities, that with
their repeated successes have shown that the "king is naked" and self-
referential practices of formal code quality or blind following of
methodologies valid for over-ruled corporations are useless advice in many
environments, and that a more socially oriented testing and user interface
design is what wins for creating online services. But I believe the
development language involved is accidental."

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.

~~~
efsavage
Actually it makes alot of sense. He's saying that the quality and innovation
of what you're building is what is important, not the fact that you're using
the newest framework. By using a mature language/environment/community you'll
be able to spend more time on your real problem and less on reinventing the
wheel.

~~~
MikeMacMan
It's a good point. Frameworks like Rails have had a big influence on the Java
ecosystem (Spring MVC, Grails, AppFuse), which goes to show you that it's not
Java -the language- that would prevent a startup from considering Java, but
rather the enterprisey, overengineered Java frameworks that haven't evolved.

------
ivenkys
This is quite a well-argued post with decent examples. A point well worth
repeating.

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.

~~~
samuel
Wasn't it obvious? I mean, this is applicable for almost any language, let it
be C++, ASP, TCL or whatever isn't considered trendy anymore but it's proven
and stable, and isn't completely unsuited for the task(COBOL, 4GL, RPG...)

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?

------
rbanffy
Isn't this based on the questionable assumption one can be as productive with
Java web frameworks as they would be with, say, Rails or Django?

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.

------
hello_moto
One common theme I learned when working with Java developers is that there are
vast amount of information out there regarding:

* 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...

~~~
minalecs
well, this generalization is a little out of left field, I suggest you go read
Zed Shaw's post about rails is a ghetto
<http://www.zedshaw.com/rants/rails_is_a_ghetto.html>

although there are improvements, its still relevant

------
bham
_but this is history, boring, and by now not very interesting_

So it is in the past, boring, and in the past and boring. OK.

