
Why isn't Java used for modern web application development? - neya
http://programmers.stackexchange.com/questions/102090/why-isnt-java-used-for-modern-web-application-development
======
latch
Part of the answer is Java itself. It's verbose, static typed, and requires a
lot of boilerplate code to do properly. The fact that classes are a compile-
time concern, rather than a runtime concern, is just such a drag. You end up
with interfaces you don't really need, only so that you can inject them into
constructors so that your app is properly decoupled and testable.

Part of it is a framework issue. Struts is horrible...absolutely, stunningly
horrible. Your controller is an XML file (seriously). Freemarker (the main
templating language) makes ColdFusion look awesome.

Play is better, but it seems built for the way websites were created in
mid-2000. JSON is still a second-class citizen. Static actions are a weird
choice given IoC is achieved via DI in a static language.

Edit: I should add that there's also the persistence story. Anyone who's done
[n]Hibernate knows that it's, at best, a mixed blessing. Even Java's NoSQL
drivers are verbose compared to their dynamic brothers (first-class hash
support is a big issue here, for some drivers in particular). I'm not sure
something like Sequel would even be possible to write, and the AR
implementations are, again, limited by the compiled-time nature of the
language and the inability of bend the syntax into a nice DSL.

Java also lacks lambdas, and generic support is weak. And what's up with int
vs Integer...the list goes on and on.

~~~
joshAg
why does a language designed around an OOP perspective need a lambda (which
comes from a functional programming perspective)?

~~~
fizx
Because otherwise you get a bunch of

    
    
        new Callable<Integer>() {
          @Override public call() {
            return 1;
          }
        }

~~~
masklinn
Or even better,

    
    
        for(final Iterator it = container.iterator(); it.hasNext();) {
            final Object o = it.next();
            println((Integer) o);
        }
    

compared to:

    
    
        container do: [:o |
            Transcript print: o; cr.
        ].

~~~
joshAg
this explanation made the most sense to me. thanks.

------
patio11
I spent three long years doing Big Freaking Enterprise Java web apps. You can
certainly do modern web dev in a Java stack (we were Struts, Hibernate,
Spring, and an internal framework). It just fought us every single step of the
way, and every time we had to do something new (that couldn't be templates off
of working code) they'd have to get one of our three best engineers to spend a
week fighting the new library into submission. Sometimes the libraries won.

The easiest way I can describe it is that everything you like about e.g. Rails
was designed as a specific dig against the Java stack. I am told Play is less
painful.

On the plus side: Java devs are plentiful, the library support is worlds
deeper than the ruby ecosystem (particular around enterprise-y needs), and it
plays well with teams of dozens (which you will probably need). I honestly
think "restricts your developers terribly" is not a bug for typical Java
projects, since the outsourcing shops contributing lots of our code base would
have been even more dangerous if the code didn't restrict what modules thy
could break.

~~~
chc
Incidentally, the bit about many of Rails' features being a dig at Java isn't
poetic license. Rails' original marketing angle was essentially "Look how
different we are from Java!"

I think that's why the difficulty of deploying Rails apps in those days wasn't
much of an obstacle — they positioned themselves not against PHP or Perl, but
against Java, so the difficulty of deployment didn't look like so bad.

------
fizx
I've been hacking Rails since 2004, and I've made the switch to Java
(dropwizard+mustache) for basic web development this year (sometimes with a
meteor-like micro-framework I rolled myself).

Benefits:

\- Higher quality code. Java is easier to refactor than Ruby, which makes up
for the lower language power.

\- Performance!

\- Actual concurrency!

\- Faster server spinup and incremental changes. Rails with 20 gems in
development mode is super sluggish.

\- Better library ecosystem!

\- Better dependency management system (maven > rubygems)

\- Better debuggers

\- Better profilers

\- Easier deployment and ops environment(java -jar myjar, vs bundle install,
ruby/passenger/unicorns)

\- Reasonable in-process metrics

~~~
irahul
> Higher quality code. Java is easier to refactor than Ruby, which makes up
> for the lower language power.

Let me rephrase:

"It's easier in Java to _rename_ identifiers than ruby, because my IDE does it
for me."

Now that's fine, but I don't see how do you conclude:

Easier to rename identifiers => Higher quality code. How on earth?

Easier to rename identifiers => Makes up for lower language power. What
language deficiencies does renaming identifiers make up for?

Other than renaming(which can be done for ruby, though it requires manual
effort), there is _no refactoring_ which Java does better than Ruby.

> Actual concurrency!

Am curious. Where in basic web development does concurrency help? As far as
servers go, evented servers(thin, mongrel) will perform as good as, if not
better, than a threaded server. And evented servers can handle much more
concurrent requests than threaded servers.

As far as concurrency at language level goes, very rarely have I needed to
spawn a thread(I go for gevent) in the controller. Controller's job is to
dispatch ASAP - everything else goes in the queue where you use EventMachine
or gevent or whatever if you need concurrent processing.

> Faster server spinup and incremental changes. Rails with 20 gems in
> development mode is super sluggish.

Rails is more sluggish compared to "stop the world. I am compiling" Eclipse?

> Better library ecosystem! > Better dependency management system (maven >
> rubygems)

As long as we are just throwing out claims without backing them, ruby library
and bundler/gem are 1000x better than mvn.

> Better debuggers > Better profilers

Not everyone is a fan of graphical everything. Going by this line of
reasoning, Windows has better support for git because gui?

> Easier deployment and ops environment(java -jar myjar, vs bundle install,
> ruby/passenger/unicorns)

`java -jar myjar` starts your app server, your web server, minifies your css,
js, migrates the db....? You can very well bundle the dependencies along with
your app for rails, but I don't see why I would do it for a webapp. Also, your
jar works only when you don't have java calling into native code. If you don't
have native extensions, ruby is platform independent as well(i.e can be
bundled).

> Reasonable in-process metrics

No ideas. What's that?

~~~
sterwill
Your Java IDE also lets you move methods and fields, extract interfaces from
concrete classes, push members up or down, find all references to a member
(reliably), view inheritance relationships, and much more. And it can do all
of those safely, warning you if you'll shadow another name. I wish I had that
stuff in a Ruby IDE.

I've used Eclipse for a long time, but not for JEE projects, and I don't see
any "stop the world" behavior when it's compiling Java. Java compile jobs run
at a low priority and rarely block another workspace job. If you want to save
a file that's being compiled, Eclipse will let you and restart the build.
Maybe you mean "stop the world I'm launching a JEE app?"

~~~
irahul
> Your Java IDE also lets you move methods and fields, extract interfaces from
> concrete classes, push members up or down, find all references to a member
> (reliably), view inheritance relationships, and much more. And it can do all
> of those safely, warning you if you'll shadow another name. I wish I had
> that stuff in a Ruby IDE.

Some of it isn't applicable to Ruby, and some of it has to be done manually.
True that you will have to rely on tests or something to make sure you didn't
shadow anything, or you renamed at all places, or you didn't rename something
which shouldn't have been renamed.

> I've used Eclipse for a long time, but not for JEE projects, and I don't see
> any "stop the world" behavior when it's compiling Java

What machine do you use? I was using a 4 gigs, dual core machine, and eclipse
regularly stalled while compiling and launching.

~~~
sterwill
I'm usually in a 64-bit Linux VM (in VMware Workstation) on a 4 core i5 Xeon
from about 3 years ago. 5 GB RAM total, Oracle Java 7 with -Xmx800M for
Eclipse. My workspace includes 50 projects, most of them are Eclipse plug-ins
themselves.

In my experience, if Eclipse "stops the world", Java is collecting garbage.
Java 6 and 7 have become much better at doing incremental collection more
often (maybe parallel is the default now?) and the result is a more responsive
UI. To me, Eclipse itself feels snappier over time (each release from 3.3 to
3.7 has felt better on similar hardware).

Another thing I've noticed is that Eclipse is significantly faster
cleaning/building large workspaces on Linux compared to Windows on the same
hardware. I assume this is a result of Linux's aggressive filesystem caching.

~~~
kamaal
I thing the core point is, Large Java application development seems to be
possible/doable only because eclipse is doing 90% of the work for you.

Without eclipse 90% of the Java dev work would come to a grinding halt.

And that says a lot of about Java and its ecosystem. And not to mention its
developers.

------
irahul
> why the hate toward Java for modern web applications?

Verbose language. But more importantly, needlessly verbose and badly designed
apis.

JSP:

    
    
        <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
        <%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
        
        <c:choose>
            <c:when test="${emails.unread != null && fn:size(emails.unread)}">
                You have ${fn:size(emails.unread)} unread email(s)!
            </c:when>
            <c:otherwise>
                You have no unread emails!
            </c:otherwise>
        </c:choose>
    

Saner templates:

    
    
        You have ${emails.unread ?: 'no'} ${emails.unread?.pluralize('email')} !
    

[http://paulbuchheit.blogspot.in/2007/05/amazingly-bad-
apis.h...](http://paulbuchheit.blogspot.in/2007/05/amazingly-bad-apis.html)

> But I can't help thinking to myself, "I could do this much faster if I were
> using Java," primarily due to my relative experience levels.

If you are more comfortable with Java, and are just beginning with Rails, it
goes without saying you will miss Java. That's not a very useful metric. Give
rails 4 weeks, then compare them for ease of use and expressiveness.

If you don't have a month to learn rails, then stick with Java.

> But also because I haven't seen anything critical "missing" from Java,
> preventing me from building the same application.

"It can be done with Java" isn't the same as "It can be done concisely with
Java".

I would say learn Rails/Django. Use them for CRUD. I have checked Java
ecosystem recently, and they are still far behind in terms of expressiveness
when it comes to regular web programming. Play framework is close - I haven't
used it personally apart from toy examples.

For long running services, depending on your needs, you can either write it in
Ruby/Python on top of some infrastructure tool(resque, zmq, celery....), or
you can write in in Java if your service is CPU intensive.

~~~
Isofarro
"Saner templates: You have ${emails.unread ?: 'no'}
${emails.unread?.pluralize('email')} !"

At the cost of throwing internationalisation out of the window. At least the
example you led with is more conducive to localisation.

~~~
irahul
> At the cost of throwing internationalisation out of the window. At least the
> example you led with is more conducive to localisation.

Right. i18n is the reason you have to import two taglibs and the template
doesn't support basic conditionals. /s

JSP is horrendous. There is not a single reason for its existence, and it
should be quarantined.

As far as i18n/l10n goes, the example I quoted was from play framework. This
is how an internationalized version will look like:

    
    
        # Messages file
        
        unread_emails=You have %s %s
        no_email=You have no email
        
        # Template
        
        #{if (emails.unread) }
            &{'unread_emails', emails.unread, emails.unread?.pluralize('email')}
        #{/if}
        #{else}
            &{'no_emails'}
        #{/else}
    

Are you arguing internationalized jsp is somehow better than this? I tried
really hard, but I failed to think of a single templating engine that's worse
than JSP.

~~~
flatline3
I like JSPX. Designers and HTML front-end engineers intuitively understand
custom tags, and any imperative non-declarative logic should ideally be pushed
back into Java or a custom JSP tag, such that you rarely see it.

~~~
irahul
> Designers and HTML front-end engineers intuitively understand custom tags,
> and any imperative non-declarative logic should ideally be pushed back into
> Java or a custom JSP tag, such that you rarely see it.

Have you used other templates say Jinja2 or Django templates? The traits you
listed aren't unique to JSPX. Jinja2 is designer friendly, doesn't have non-
declarative logic, and is pleasant and concise to use.

ERB(or slim or haml) allows embedding code in templates, but that doesn't mean
you are mandated to do it. Java will allow you to put n non-public classes in
one file - that doesn't mean you code your whole app in a single .java file.
Just because it's possible is hardly an excuse for it being bad.

There are use-cases where code in templates are useful. I would rather not
jump through the hoops of defining a custom tag for an one-off use-case.

------
kilemensi
Google (at least Gmail), LinkedIn, etc are to me modern web applications &
AFAIK they are written in Java (or at least partly in Java) and I'm not
counting countless enterprise web apps.

Java is what they call mature technology. It's past the hype and language
flame war phase. Those who know its value, just use it to GTD without any
ceremonies.

------
mgkimsal
I've worked with PHP for 16 years, and with Grails for almost 5. There are
some aspects of Grails and Groovy that make me more productive than developing
in PHP. GORM simplicity and expressiveness, and CriteriaBuilder stuff,
combined make using direct SQL very rare (required in a few cases, but rare).

However, there are aspects of PHP that make things more simple, and this gets
down to somewhat of a cultural thing. Of the PHP people I know, many (most?)
of them have done some server setup and understand the entire request stack. I
know a lot of PHP people don't grok all that as well, but of the people I know
personally, many do. That number is far higher than the number of Java folks I
know who really grok the full web stack. I'm not saying none do, but... many
don't have to as much as PHP folks.

A friend of mine who's done Java for a decade (and Groovy some too) was
confused by a complaint I was having about Java web stuff. Specifically, I was
(am?) having some trouble getting session replication stuff working. We need
to load balance web servers, and I really want to avoid server affinity on a
load balancer. In PHP, sessions are serialized to disk, but serializing to
memcache or some other database is pretty simple. Java... not so much.

My friend's confusion was "why are you doing that? just tell the ops guys to
set it up". Well... I _am_ the ops guy. Which gets to the culture of dev
stacks. Historically, the Java shops I've seen inside are larger, and there's
a bigger separation of concerns - the server/ops person often isn't even much
of a developer, they just drop in a war file and keep websphere running, etc.
Again - YMMV, but that's been mostly what I've seen.

The 'separation of concerns' here is the heart of the issue. In PHP, all
session stuff is handled in code. In Java... well, your app server takes care
of that for you - 'out of the box' you don't have any real direct control over
how they're handled, and configuration of such is never done in code, but at
the server level.

I'm reminded of PHP in 96/97. If you were doing PHP back then, it's because
you really loved it, not because it was your job, and you really needed to
grok everything about everything to get it set up and working (locally,
anyway). If you're really set on using alt.java tech, you likely have a
greater commitment to getting your hands dirty in multiple levels.

disclosure - i run groovymag.com and have a bias towards all things grails and
groovy :)

~~~
democracy
I can't see why you can't serialize session to database or memcache or
anything else if you want. The amount of code involved is almost zero... Also
I don't see a reason to have a shared storage for session objects in a
scalable distributed application you are trying to build.

In Java you could, for example, use ehcache with out-of-box replication -
simpler than using external C-based application like memcache.

And in Java world you have to deal with different applications servers
(Weblogic/WebSphere/JBoss etc.) where apache http and nginx installation and
configuration is very primitive in comparison. Yes, it involves sharp skills
when it comes to huge loads and replication, but that's another story.

Your friend is probably a young junior developer, you can't be a serious java
developer without a decent server skills - there is no ops team at home to do
it for you and you can't really gain a lot of knowledge only doing stuff at
work.

~~~
mgkimsal
Friend in question is certainly not a young junior dev - >10 years of dev
experience, 8 in java, and does java training. Trainers may be more focused on
language stuff vs admin stuff, so I cut some slack there. But.. the majority
of java people I've known have been developers only, who don't do any server
admin. Again, not saying java devs who know sys/server admin don't exist, but,
the ones I know who do that aren't 'java devs' in the sense of only doing
java, but tend to be polyglots with experience from multiple backgrounds.

I'm not sure why you'd _not_ have a shared storage for session data in a
multi-server system. What else do you suggest?

<http://ehcache.org/documentation/configuration/configuration> \- that's an
insane amount of configuration it looks like compared to something like PHP.
It also looks like you're tying yourself to a specific caching solution vs
having generalized session data.

------
pkaler
Java is a language that is in a weird space.

It doesn't compile to binary like C/C++ and it isn't high-level and
interpreted like a Ruby or Python.

It's a weird middle-times language. It originally appeared in 1995 and is
somewhat pioneering in the web space. But it isn't as clean as C# since C#
appeared in 2001 and was able to learn from the mistakes of Java. It's
definitely not as clean as Go which appeared in about 2009 and was able to
learn from the mistakes of C, C++, Java, and C#.

The framework choice is probably more important than the language choice.

There is a fragmentation of frameworks. Starting a greenfield project with
Spring, Struts, Stripe, WebObjects, etc would probably be a bad choice. Play
is probably a reasonable choice.

But this is not an issue with Ruby or Python. You're probably going to pick
Rails or Sinatra as your choice if you go with Ruby. You're probably going to
go with Django if you go with Python.

Tyranny of choice is a problem with Java frameworks.

~~~
TheCondor
Spring is a bad choice?

~~~
rabbitfang
Yes. Endless XML configs, and a ton of overhead to get started. Anyone can get
productive with Play in 5 minutes. Spring + Hibernate were smart choices in
2003, but no longer the case.

------
pairing
When starting web development, I found it easier to learn Ruby and the Rails
Framework from scratch than to use Java which I had several formal classes in.
I think that says something about Java's documentation/community support.

Ruby/Rails has railstutorial.org, tryruby.org, rails for zombies/code school,
and railscasts. All these high quality beginner resources made using Ruby
instead of Java an easy choice.

The other reason for me is that I find the code I write in Java to be too
wordy and found the more concise syntax of Ruby refreshing and fun.

~~~
taligent
I don't think the problem is Java documentation/community support.

It's really that with the exception of Play/Grails/Vert.x the frameworks are
horrifically over-engineered by developers who live and breathe in the
enterprise space. Nobody has ever really cared much about smaller, more
startup land developers. So Java has required so much knowledge and
involvement just to do the simplest things.

I would take a look at frameworks like Play for the future of the platform.

------
v33ra
Here's an old HN thread: Any web startups using Java? -
<http://news.ycombinator.com/item?id=1932821>

------
Ogre
I work in an industry where C++ still rules. I haven't ever written more than
a few lines of Java. However, here's a job posting from our web team:
[http://us.blizzard.com/en-
us/company/careers/posting.html?id...](http://us.blizzard.com/en-
us/company/careers/posting.html?id=120000E)

Java is the only language mentioned by name. Last time I talked to them about
a thing I was working on and mentioned I would soon have (now actually do
have) a Python implementation, the response was basically "That's neat, but
can you do it in Java too?"

So, in my little world at least, web development is the only place where Java
actually does get used.

------
KenCochrane
I programmed java web apps for 10 years before I switched to python, 4+ years
ago. I feel that I'm much more productive using python and can get much more
done in a shorter period of time, and to be honest, I'm much happier when I
develop in python. Here are some of the reasons why I think python is better
then Java based on my personal experience, your milage may very.

Web Frameworks:

When I first start programming web apps in Java, Struts just came out, and it
wasn't great, but it was the best thing available. I created a bunch of struts
apps, and a few in other frameworks along the way. Whenever a new framework
came out (Tapestry, Wicket, GWT, stripe, grails, AppFuse, Play, RichFaces,
Spring, etc), I would try it out and see if it was any better, and most times
it was only a little better, and sometimes not better at all. I do have to say
the play framework is a step in the right direction.

Batteries not included:

One of the most annoying parts of Java was the fact that most of the libraries
that you use were not included in java itself, you had to include a ton of 3rd
party libs from places like apache commons. If you use something like
hibernate with any other large library, you end up in Jar dependency hell,
where hibernate needs one version of a jar, and something else needs another
version. If you load the jar files in the wrong order, you are out of luck.
You need to depend on tools like maven, and ivy to manage your dependencies,
and this just brings in more dependencies into your project which results in
projects being huge. I had some war files 100MB+ war files for the simplest
web apps.

Too many options:

For some reason there seems to be way too many different ways to do the same
thing in Java. There are over 38 different web frameworks for java according
to wikipedia
([http://en.wikipedia.org/wiki/Comparison_of_web_application_f...](http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java))
and 23 different ORM's ([http://en.wikipedia.org/wiki/List_of_object-
relational_mappi...](http://en.wikipedia.org/wiki/List_of_object-
relational_mapping_software#Java)) just to name a couple of examples. If you
look at other languages they have a more reasonable number. Some people think
that having lots of options is a good thing, but it isn't it leads to a lot of
wasted effort in the developer community, everyone is reinventing the same
wheel, and if you are a new person to the language you have too many option to
pick from.

App servers:

Java web applications are really heavy, and require a lot of resources to run.
They are especially memory hungry. Like any piece of software they can be
tuned to reduce their resource footprint, but compared to other languages
their out of the box setup is horrible. In my past I have used weblogic,
websphere, Jboss, tomcat, and jetty. I only used the first three when I was
forced to use EJB's, but even if you aren't using EJB's they were large app
servers and sometimes hard to configure and get running correctly. Tomcat and
Jetty are much better and easier to setup, but are still resource hogs.

App Hosting:

If you aren't running your own server it is real hard to find shared hosting
for your java apps at a reasonable price. The main reason is because java apps
require much more memory compared to other languages, so it doesn't make sense
for a shared hosting provider to spend their valuable RAM running a java site,
when they could run 5 php sites in the same place. That means there are less
providers offering java hosting, which in turn means higher costs to run your
website.

Development Time:

When I developing in java, I found myself much slower then what I can do in
python. I would need to make a change, compile, redeploy and then test, and
this slows down the iterative process. I know there are ways to make this
faster, but even at it's best, I felt much slower then what I can do in
python.

There is also a lot less boilerplate code to do the same thing in python, so I
spend less time developing the code as well.

Java just feels over engineered in a lot of parts, A lot of the API's and
interfaces are just way to complicated for what you want to do. And everyone
and their brother thinks they are a java architect and this results in big
complicated systems that are hard to use and develop with.

IDE:

When I was developing in Java, I felt stuck to the IDE, I was lost without it.
IntelliJ is the best IDE's on the market, and it was hard switching to python
because there wasn't anything like it for python. So instead of an IDE, I just
used textmate, which is just a normal text editor. It was hard at first, but
because it was just a text editor, it was a really fast and responsive
application. I could open my whole project in a few seconds, whereas when I
want to open a project in an IDE it could take a minute or more, with a
machine with a ton of RAM. The makers of IntelliJ came out with a python
editor called pycharm, I bought it when it first came out, and it is great.
But what I realized is that I don't need an IDE for python, I'm fine with a
text editor. When I go back to working on Java web apps which I have to do
from time to time, I try to use the text editor, but I haven't quite mastered
that yet. I personally need the IDE for Java more because If I mess up
something it takes longer to recompile and redeploy, which slows me down.

ORM:

When I first started using Hibernate as an IDE, I thought it was great, it had
it's problems, and it wasn't perfect, but it was better then what I was doing
before. I was happy with it, until I did an application with Django's ORM on a
python project, and that opened up my eyes, that is how an ORM is suppose to
work. After that project I went back to hibernate, and I just felt
disappointed, and longed for going back to Django's ORM. Another great python
ORM is sqlalchemy, which is similar to Django's ORM, but a little different. I
have limited experience with ROR's ORM, but from what I remember, it was
pretty good as well.

Templates:

The web templating systems in Java aren't that good, and I think I have tried
them all (tiles, freemarker, velocity, etc). Most of them offer only basic
functionality and are a pain to work with. On the Python side, my two
favorites are Django templates and Jinja2, they have everything that I could
need in a templating engine, and are really easy to use.

~~~
facorreia
I think all of this was true 4 years ago. But Java EE 6 has changed a lot of
this. My main experience has been on the Microsoft stack, but I have learned
and worked with a lot of tech, including Rails and Django. Last year I worked
on a project for which we chose Java EE 6.

There's a lot of good stuff there; for instance simple, bloat-free
architecture, JPA (the new persistence architecture), CDI (context and
dependency injection), JAX-RS (REST), JSF + PrimeFaces (very productive front-
end development) and lightweight, fast web application servers (Tomcat 7,
Glassfish).

And you have access, when and if you need it, to a very mature, stable and
capable set of libraries, open source projects and tools. Plus the ability to
deploy to almost anywhere including PaaS platforms.

So I think there's a lot to like in modern Java.

~~~
KenCochrane
For what it is worth, I have used Java 7, JPA (with hibernate), tomcat 7 and
glassfish, and I didn't notice much difference. Jersey (JAX-RS) is pretty
nice, one of the better libraries to come out of Java in a while.

I do agree that Java is moving in the right direction, but it is a very slow
progression. I think the major cause of the slowness is because of the fact
that SUN was bought by Oracle, and it took a little while for that to settle
down, and now things are slowly moving forward again.

One of the things that Java did right was their WAR files. It is the envy of
most other programming languages. You compile your WAR file, and deploy
anywhere assuming it is a compliant servlet container. I wish Python had
something like this.

You are right the popularity of PaaS's like dotCloud make it much easier to
deploy and run your application. On dotCloud you just need to push up your WAR
file, and you are running, by far the easiest of all the languages to deploy.

I really like Java as a language, I just think it has a long way to go on the
web application front, before it can catch up to the features and speed of
development of the other languages.

~~~
swah
For folks outside of JavaEE, its common to deploy jars though. I have never
run the software that takes .wars.

~~~
KenCochrane
You deployed jars for web applications?

War files are not JavaEE, you might be thinking of EAR files.

A war file is just a jar file with a different name and manifest, and expects
a few things, WEB-INF directory with a web.xml and that is about it.

More info can be found here:
<http://en.wikipedia.org/wiki/WAR_file_format_(Sun)>

~~~
swah
Sorry for my mistake, I associate WAR files with Application containers like
JBoss and (IIRC) Tomcat. I only deployed with embedded jetty :)

------
tzury
Just remember when you talk about "cool" and popular that, Google+, GMail,
LinkedIn, and many parts of Twitter are Java.

~~~
raverbashing
For twitter: JVM != Java

Also remember that Google uses C++ as well for their infrastructure

LinkedIn, yep

~~~
rabbitfang
Google is heavily reliant on Java. LinkedIn and Twitter both use Scala and
Java. I'm not really sure that pointing out that Google has some C++ code
really disproves that Java is used heavily at google. Java is still very
widely used, more so than more fashionable languages like python and ruby, but
the syntax is a bit long on the tooth, hence the popularity of Scala, Clojure
and Groovy.

~~~
raverbashing
" I'm not really sure that pointing out that Google has some C++ code really
disproves that Java is used heavily at google. "

Of course not

"Java is still very widely used, more so than more fashionable languages like
python and ruby""

Yes, but "widely used" is a tricky term, I'm sure cases both for and against
can be found.

But to talk about Google, last I heard it's only possible to develop
application there in the following languages: JS, Java, C++, Python (there are
exceptions of course, for specific libraries or things like ObjC for iOS)

------
jfaucett
As a young developer (early 20's) I think Java's lack of usage in webdev has
to do with several "problems". 1.) Java has the rep of being bloated and slow.
(At least when compared to C/C++) 2.) Related to #1, almost all the tools the
majority of webdevers use are written in C/C++ and not Java. For instance,
Apache, Nginx, Redis, MongoDB, MySQL, SQLite, Webkit, V8 - which gives me the
feeling that using/improving C/C++ gives me a better understanding of my
toolset whereas Java doesn't have any perceived added benefit. 3.) For
Application Development itself, using scripting languages like Ruby/Python/PHP
makes for BLAZING fast development especially when using a framework like
Rails. 4.) The LAMP Stack (if implemented correctly) can handle a LOT of
traffic, I'm talking millions of daily users.

So this leaves almost every web developer (I'd say around 98%) with no reason
to use Java - ever. Why should they? With the current tools, I can build
highly scalable apps extremely fast and because I'm using scripting languages
I'm free to experiment, mix/match, combine, and build new tools in innovative
ways. Also, I think because Java is associated with the group of C/C++ and
"lower level" languages it really does loose cred simply because it can't
compete in effeciency terms with those languages.

Personally, as a programmer who loves C, Ruby and Haskell (so yea I'm biased
but who isn't?) just looking at the Syntax of Java makes me seriously wonder
what Sun was thinking.

~~~
rabbitfang
You're criticizing Java for being slow, and then presenting Ruby as an
alternative. You do realise that Java is up to 100 times faster than Ruby:
[http://shootout.alioth.debian.org/u32/benchmark.php?test=all...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=java).
And on multicore systems Java up to 300x faster than Ruby:
[http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=yarv&lang2=java)

...alternatively combine the performance of Java with a highly expressive
language e.g. Scala

~~~
jfaucett
yes, but if you noticed I'm comparing Java to C in terms of program language
speed. I'm comparing Java to Ruby in development speed NOT language speed, I
thought this was obvious... sorry, If I wasn't clear enough above.

~~~
rabbitfang
You were clear, but if you're going to compare languages you can't cherry pick
which features to compare. You compared Java to C performance and then Java to
Ruby in terms of expressiveness. Since Ruby does not have the performance of C
and C does not have the expressiveness of Ruby it's not really a fair
comparison to Java.

------
st3fan
I do a lot of work in Python now, which is great. But the one thing that I
really really really miss from Java is better dependency management and
packaging.

I wish I could just create a .war file for my Python project and copy it to a
deploy directory on a server to get it going.

Using a virtualenv and pip or easy_install works ok but a simple maven config
to define my project and it's dependencies is still lightyears ahead of the
mess we have in Python now.

It is _really_ difficult to beat: 'mvn package && scp target/my-app-1.0.war
server:~/deploy/'

I hope Python will get there.

~~~
edwinnathaniel
... and if you wouldn't mind to spend some more time...

<http://maven.apache.org/plugins/maven-deploy-plugin/>

"mvn deploy" is probably all you need? :D

------
mks
We (plumgine.com - in private beta) have been using Java with a success with
Play Framework and asynchronous AJAX fronted (some parts with Backbone.JS).

I have been using Java for a while (8 years - J2EE, Android, some desktop
utils) and back in the JSF days I used to hate the Java web with a passion.
Then I found Stripes (step in a good direction) and Play Framework (absolutely
awesome Java web framework).

These days I can whip out prototype in Java+Play Framework faster than
anything else.

Some of the reasons:

* I don't have to worry about naming methods/members because I can safely rename them later

* I can easily map Java objects to JSON and back using Jackson

* most of the time I don't worry about database schema - Hibernate (JPA) generates it for me

* Play Framework works in the "hit refresh" mode to see changes

* deployment to Heroku is as seamless as any other.

There is increasingly more action going on in the browser in JavaScript and I
think Java (with Play Framework) is a great tool for building backend APIs
that will be consumed by your JavaScript client.

------
moondowner
Who says it isn't?

Spring MVC + Spring Data JPA or Mongo + Thymeleaf for templating + coffee-
maven-plugin for Coffee to JS transpiling and you're good to go.

I think the first comment on the question is very true:

> "I think you're incorrect: it is still used, it's just lost cool factor."

------
hermanhermitage
Some syntax issues (no function pointers, no lambda, no rich literals,
enforcing everything to reside in an object) endears it to Enterprise OO
mindset where you want large teams of programmers working "efficiently" - but
ultimately a risk conscious and ego driven manager just wants a large team of
developers to further their career - and doesn't care how much boilerplate is
present or how few lines of code actually do something productive. These are
slowly being addressed with newer versions of Java, but it's a long hard road
out of hell... and the mental association of Java as enterprise VB is here to
stay.

I'd say it's guilt by association with the early years of a java. It reminds
lots of people of the bad old days of programming. Getters and setters instead
of pure data. Using java objects to hardcode schemas in the middle tier.
Horrendeous death by meaningless patterns (form over function). Gigantic
libraries configured by XML (how can you take a modern language seriously that
doesn't have rich literals). Build dependencies and process that again can't
be efficiently specified in the native literal forms of the language.

Finally Java has no useful pedigree as a client side or UI language. Thus the
J2ME fiasco. The AWT fiasco. The android sluggish UI fiasco.

You can write a modern web app in BCPL, or Java. But for many people the other
options are simply more appealing.

------
cromwellian
Many Google services are backed by Java on the backend, and Closure compiled
JS or GWT on the frontend.

~~~
cromwellian
To flesh this out a little more:

The question should be "Why isn't Java used by startups or for small
projects?". Java certainly used for "modern Web apps" at more established
companies. The issue is one of speed vs scale. Startups need to get to minimum
viable product. They are usually small teams of 1-3 engineers, and value
iteration speed over performance or maintainability. Running up against
scalability issues or team code code maintenance issues is a problem "you'd
like to have", that is, by the time you reach that stage, it's a sign your
initial implementation helped you over the initial hump of getting customers
or investment. You can afford to rewrite the app at that point.

A company like Google can afford the luxury of building things for scale up
front, even though they may be wasting their time implementing scaling for
something that might get no users, because they can absorb the loss.

At least, that's my opinion, that many many "cool", "hip", "modern" companies
build small apps with small teams where iteration speed and simplicity are the
greatest requirements.

~~~
agiamas
Correct but also a company like Google knows that the moment they put up a
link in the frontpage they can drive vast amounts of traffic towards the new
property. Secondary reason is that a web app from Google that doesn't scale is
really bad PR and draws comments like "omg, lulz it's Google and they can't
handle traffic???!!!1!"

Hence, they build with scaling in mind. A startup has none of these concerns
and just cares about time to market and making some money to convince VC's
that it's worth investing.

------
TrevorJ
I think because of it's age, the pitfalls and limitations of the language may
be more well understood, so it may suffer from a sort of 'grass is greener'
effect.

~~~
Ogre
Its age relative to what? Python is older by any measure, and the first public
release of Ruby was only 7 months after Java's. Java certainly had a higher
profile than either at the time, but they're all from essentially the same
period.

[http://en.wikipedia.org/wiki/Java_%28software_platform%29#Hi...](http://en.wikipedia.org/wiki/Java_%28software_platform%29#History)

[http://en.wikipedia.org/wiki/Ruby_%28programming_language%29...](http://en.wikipedia.org/wiki/Ruby_%28programming_language%29#Ruby_1.0)

<http://en.wikipedia.org/wiki/History_of_Python>

~~~
batista
Age in the spotlight doing web development.

Not age since the development of the language.

Mid-nineties it was CGI and mostly Perl.

Then Perl started to fade, and in the late nineties, early '00s, it was all
Java and PHP.

Then Ruby/Python etc co started to catch on in the mid-00's.

And already Ruby and RoR is considered "passe" and old, and fadsters turn to
Node.js and such.

Seems to be a 5-7 year cycle.

------
Herbert2
This is just my experience but if there has existed a common line of thinking
with the rabid Java fans I've worked with, it would be closed mindedness to
the point of being its own brand of Stockholm syndrome. The thinking that
whatever the project at hand may be, a Java based solution is always the
correct answer and there is nothing to learn from alternative platforms. I've
heard "Why would anyone want to use anything other than Spring?" or "C# is
shit" more than once. However, if you were to compare the experience of using
Spring + Eclipse to C# + ASP.MVC + Visual Studio, you'd have to be pretty set
in your ways not to admit that the latter is a much nicer platform to work
with and that the Java eco-system shouldn't take something away from it.
Having a standard web framework (ASP.MVC) makes .NET teams miles more
efficient than the framework fragmentation that is Java web dev.

And if you're comparing it to Rails or Django, I honestly don't think you can
easily find a 3 or 4 engineer Spring team that could deliver a product as good
(or scalable) as Instragram in the 2 years it took them to do it in Django.
You just can't iterate as fast.

~~~
berntb
>>the rabid Java fans I've worked with [closed mindedness]

It is hard to argue against anecdotal evidence, but of the cases you mention
-- java, Rails, Django -- imho, it is not exactly the Java people who seem to
be the worst language/framework fanatics...

(That said, scripting languages eat static languages' lunch for development
speed in most every case I've seen.)

~~~
Herbert2
That kind of framework enthusiasm doesn't really stem from the closed minded
mindset I was referring to. Most Ruby & Python devs I've met would admit that
Java is a much better choice than their perspective languages for something
like that requires distributed concurrency and speed (like Cassandra or
Redis). The people I'm talking about are the ones that wouldn't look seriously
at RabbitMQ because it's written in Erlang, not Java.

~~~
berntb
I got your point, I wrote that according to my personal experience the other
cases are quite a bit worse. Which is worth as much as your personal stories.

------
democracy
It is not used for 'Show HN my useless toy I built last weekend'. It is widely
used in many start-ups.

------
ExpiredLink
This assertion is simply wrong. Java is number one for Enterprise web
application development.

[Edit] Statistics:
[http://w3techs.com/technologies/overview/programming_languag...](http://w3techs.com/technologies/overview/programming_language/all)

------
eternalban
Because Web is type-less, purely text-based, and dynamic. And Java is not. I
remain a Java aficionado, but would reach for it last in the Web tier. Put a
dynamic language upfront and hook it to a SOA-based Java backend.

------
leothekim
I actually think the IDEs for Java, e.g. Eclipse and IntelliJ, are quite
evolved and help speed webapp development, and they do it in ways that make up
for Java's verbosity and boilerplate.

For me a lot of the web frameworks for Java felt cumbersome and I found that
Java worked better when functioning as a high-throughput backend service
instead of handling front-end UI. Oddly, with Java, I was more concerned with
concurrency issues, GC tuning, threading, and other systems-y problems, and
with Python I was more concerned with concise and Pythonic syntax and faster
iteration.

------
mark_l_watson
I think that Java still has a strong role for writing REST web services and
heavy lifting back end stuff because of the robustness of the JVM and lots of
great tools and frameworks.

That said, most of the web services I have written this year are in Ruby (with
some Python in the last few weeks).

For web app front ends I really prefer lighter weight tools like Rails.

------
gbog
No it is not the coolness factor, it is the paradigm. Java forces you to use
OOP and OOP is not very fit for web development: you want to answer fast to a
stateless request by checking some data trough different filters (eg a
template), you don't want to recreate a full world of objects and pass along
some messages.

~~~
franzus
Hmm, last time I checked all the "new" frameworks were OOP too. Be it rails or
django - they all have some kind of OO paradigm they adhere to.

~~~
gbog
Yes, and there is this ORM impedance mismatch thing. I stopped writing classes
for all tables and it removed many useless code and many issues related to
stateful methods. Just one example: if you delete a book with book.delete()
then how come you can two or many lines later change its title with book.title
= Foo?

------
sgt101
We use Java to develop web apps because while we could use anything ( I run a
research team) I know that I will face problems downstreaming the work if we
do. The application support groups can get a Java developer with a whistle,
the same is just not the case for any other language, apart from possibly PHP.

------
flomo
Framework of the month fatigue.

------
kephra
imho, Java is a great tool when it is deployed for its original goal: Platform
independent GUI clients. Unfortunate its now mainly used on the server side,
where it fits badly.

The main reason I'm not using Java on server side is memory footprint. A
typical Lighttpd, fastcgi, Rails, MySQL stack runs well within 256mb of memory
on a Xen instance. A typical Apache, Tomcat, JBoss, Hybernate, Spring, Oracle
stack requires 4GB or more on a root server.

I think most startup coders shy Java, because they know it mainly by
maintaining enterprise dead horses and bloatware.

See: Tate, Bitter Java, ISBN: 193011043X

~~~
sandGorgon
I seriously recommend that you re-look your stack. Java is simply the most
performant (RAM and CPU) stack vs Rails in a pure apples-to-apples comparison.

The two stacks you have compared are apples to watermelons - here are a couple
of questions:

1\. Why both Tomcat and Jboss ? Choose one or the other. In fact for the best
performance you can run your application on Jetty.

2\. Mysql vs Oracle ? you need to compare equally. I hope you do realize that
JDBC/JNDI are perfectly compatible with Mysql - more so, since they are the
same business entity.

3\. Lighttpd vs Apache is again an unfair comparison. You can perfectly run
Lighttpd in front of Tomcat.

I seriously suggest you re-evaluate Java if you are purely looking for
performance. Developer productivity is a whole different story altogether.

~~~
kephra
all true - but my unfair comparison was between the typical java enterprise
dead horse, and a typical startup stack.

I did not compare Java best practice for one reason: The enterprise bloat is
how Java is perceived. Its not about why Java is not suited for startups, but
why Java is not choosen by startups.

------
karianna
Disclaimer: This is cribbed from my upcoming "The Well-Grounded Java
Developer"

\---------------------

If you investigate Ola Bini's pyramid where languages fall into static,
dynamic and DSL layers you'll see his arguments for what type of programming
tasks suite which layers. Java sits firmly in the stable layer, and so do all
of its various web frameworks.

As expected for a popular and mature language, Java has a large variety of web
frameworks, such as these:

Spring MVC, GWT, Struts 2, Wicket, Tapestry, JSF (and other related “Faces”
libraries), Vaadin, Play, Plain old JSP/Servlet

Java has no de facto leader in this space, and this partly stems from Java
simply not being an ideal language for rapid web development.

The former leader of the Struts 2 project, a popular Java-based web framework,
had this to say on the subject:

"I’ve gone over to the dark side :-) and much prefer to develop in Rails --
for the conciseness mentioned above, but also because I don’t ever have to do
a “build” or “deploy” step during my development cycle any more. But you guys
and gals need to be reminded that _this_ is the kind of thing you are
competing against if you expect to attract Rails developers ... or to avoid
even more “previously Java web developer” defectors like me :-). Craig
McClanahan, Oct. 23, 2007"(<http://markmail.org/thread/qfb5sekad33eobh2>)

Java is a compiled language, and as alluded to previously, this means that
every time you make a code change to a web application, you have to go through
all of these steps:

1\. Recompile the Java code. 2\. Stop your web server. 3\. Redeploy the
changes to your web server. 4\. Start your web server.

As you can imagine, this wastes an awful lot of time! Especially when you’re
making lots of small code changes, such as altering the destinations in a
controller or making small changes to the view.

If you’re a seasoned web developer, you’ll know that there are some techniques
you can use to try and solve this problem. Most of these approaches rely on
some sort of ability to apply code changes without stopping and starting the
web server, which is also known as hot deployment. Hot deployment can come in
the form of replacing all of the resources (such as an entire WAR file) or
just a select few (such as a single JSP page). Unfortunately, hot deployment
has never been 100 percent reliable, and the web server often still has to
perform expensive recompilation of code.

If you must use a Java-based web framework, I highly recommend products called
JRebel and LiveRebel (<http://www.zeroturnaround.com/jrebel/>). JRebel sits in
between your IDE and your web server, and when you make source code changes
locally, they’re automatically applied to your running web server through some
genuinely impressive JVM trickery (LiveRebel is used for production deploys).
It’s basically hot deployment done right, and these tools are seen as industry
standards for solving the hot deployment problem.

Generally speaking, Java-based web frameworks don’t reliably allow you to have
a fast turnaround time for your changes. But that isn’t the only concern with
Java-based web frameworks. Another factor that slows down rapid web
development is the flexibility of the language, and this is where static
typing can be a drawback.

In the early stages of developing a new product or feature, it’s often wise to
keep an open-ended design (with regards to typing) of the user presentation
layer. It’s all too easy for a user to demand that a numeric value have
decimal precision, or for a list of books to become a list of books and toys
instead. Having a statically typed language can be a great hindrance here. If
you have to change a list of Book objects into a list of BookOrToy objects,
you’d have to change your static types throughout your codebase. Although it’s
true that you can always use the base type as the type of objects in container
classes (for example, Java’s Object class), this is certainly not seen as a
best practice—this is effectively reverting to pregenerics Java. As a result,
choosing a web framework that’s based on a language in the dynamic layer is
certainly a valid option to investigate.

~~~
kilemensi
"1. Recompile the Java code. 2. Stop your web server. 3. Redeploy the changes
to your web server. 4. Start your web server. ... Unfortunately, hot
deployment has never been 100 percent reliable, and the web server often still
has to perform expensive recompilation of code."

\- Last I checked i) the hot deployment in Tomcat/Jetty/SBT/etc is pretty
solid, especially if we are talking development. ii) Java supports incremental
compilation which means you only need to compile what has been changed,
especially if we are still taking development phase again. Unless you compile
after making changes to 100+ files, I don't see how expensive this step can
be.

"Generally speaking, Java-based web frameworks don’t reliably allow you to
have a fast turnaround time for your changes. But that isn’t the only concern
with Java-based web frameworks. Another factor that slows down rapid web
development is the flexibility of the language, and this is where static
typing can be a drawback."

\- This argument about dynamic typing faster/better than static typing is just
BS. Each offers it's own advantages and can be better/faster depending on
where/when/how you apply it and how good a developer are you at actually using
their power. Your first example of changing number value to have decimal
precision can be achieved in static typing languages like Java/C# just as fast
and reliably when one uses refactoring. Your second example of changing list
of Book objects to a list of BookOrToy objects, could have been avoided all
together by coding to interfaces and not concrete objects. If that has failed,
refactoring again solves this.

~~~
morsch
Not only does hot deployment work almost always, so does in-place compilation
of modified code within deployed modules while connected to a remote
application server in debug mode.

~~~
karianna
To both of these points, you still have classloader issues which cannot be
resolved (App/Web server vs application classloading). This is one of the
reasons that Java 8 is going down the modular Jigsaw route (taking ideas from
OSGi along the way). Some web/app servers have put together clever tricks over
the years and JRebel also helps, but it's certainly not foolproof.

I'll concede that the static vs dynamic language gap is narrowing in terms of
flexibility (and yes BookAndToy is a _very_ contrived example), but dynamic
language fans love the fact that you don't have to refactor at all.

------
dotborg
Modern web application development process is not limited to only one language
or one framework.

------
1010011010
Because Java sucks. Please, for the good of our industry, please stop using
it.

------
terjeto
It's mainly the coolness factor. Oracle's ridiculous Java lawsuits also
contributes to that.

~~~
taligent
I don't think that the Oracle lawsuits have made a single bit of difference to
anybody.

Oracle isn't the only big fish in the Java space.

~~~
cldrope
But they own Java.

I'm sorry, but as a Java developer seeing Oracle pick it (anything Java) up
like a dead fish and try to see who they can smack big money out of is
horrifying.

It goes against the culture of Java that I'm familiar with. I've been learning
other languages on the JVM for the express purpose of being ready to jump ship
if I need to with those other languages. (Jython can jump to Python, JRuby to
Ruby, Java to C#/C++, and Scala can be mapped to something I'm sure).

~~~
lnguyen
Don't forget IBM. (Not that they might seem any better than Oracle...)

They own a large chunk of the enterprise Java space with WebSphere. And
they're also are a large driving force for Eclipse (was also their original
code).

------
taligent
It IS used extensively for modern web application development just not by a
lot of startups. In the enterprise space you really only see Java and .Net
used for the core pieces.

One reason that Java is becoming less popular is that you don't need to use
Java (the language) to be a part of Java (the ecosystem). You can use Groovy,
Scala, Python, Ruby etc which are often less verbose and have more exotic
features. So developers can try new languages out but don't need to abandon
their existing libraries. Best of both worlds.

This is the approach that companies like Twitter and Etsy have taken.

