

A Java EE Startup: Filtering information with zeef.com - john-waterwood
http://www.adam-bien.com/roller/abien/entry/a_java_ee_startup_filtering

======
manishsharan
JSF ? Oh those gullible youngsters !

JSF is the slowest way to do web development for rich client UI: starting
stopping J2EE servers is time consuming. HTML templating is difficult; you
can't see what you screen looks like until you serve the page from your J2EE
server .Also JSF is an unnecessary abstraction over HTML : it is much easier
to maintain state on client itself using any of Javascript libraries like
React or Backbone or others. You are much better off using REST servlets or
REST Spring MVC with your javascript. JSF impedes the growth of features or
functionality on a page: as you add more widgets to you page like JQuery
plugins , you will be suprised by the amount of backend code you will have to
write. Ultimately ,you will eventually resort to hacks and you page state and
you JSF state for the page will deverge. Sadly you wont discover this mess
until you are waist deep in this pile of muck.

JPA is pretty awesome ; however I have learnt over the years that you need to
fine tune your queries using explainplan rather that relying on generated
queries; define the views on the db itself and load them with JPA; this way
the others frameworks or related application ,like a ASP application or a
python web application or reportng application, can also leverage the same
data and view.

~~~
smoyer
JSF isn't the greatest, but it's improved a lot starting with version 2.0. I
can indeed see a preview of what my page will look like (with templates
applied) right in my IDE. The fact that you called it J2EE makes me think
you're talking about the "old" Enterprise Java. I abandoned it for a while
back then too - it was no fun to use!

~~~
manishsharan
I should have clarified: previewing a page in an IDE is not enough in my use
case (banking): I would want to preview my page on different devices'
browsers.

~~~
henk53
>I would want to preview my page on different devices' browsers.

What's stopping you?

With JSF you can write normal HTML that you can load on every device. See
[http://jdevelopment.nl/jsf-22/#1111](http://jdevelopment.nl/jsf-22/#1111) and
for the older somewhat less capable version:
[https://en.wikipedia.org/wiki/Facelets](https://en.wikipedia.org/wiki/Facelets)

------
eranation
Modern Java EE has taken a lot of influence from other web frameworks. It is
now much more convention over configuration than it used to be. I think it
just lacks a new MVC module as an alternative to JSF. If only jersey 2.0's mvc
templates were added to the core, I would have considered it instead of other
alternatives (e.g. Adding routing to a view from JAX-RS, right now it's not
trivial and meant mostly for "services" e.g. API methods vs JSF for your
friendly neighborhood MVC. I think JAX-RS is much more friendly and familiar
to people coming from other web frameworks. JSF is not too, well, RESTful and
feels a little outdated to me, although it's very powerful...)

(Dropwizard uses JAX-RS by the way if I'm not mistaken)

Now with Java 8, Java EE is quite a powerful and productive framework, and the
performance is pretty predictably just awesome.

~~~
mikehaggard
> I think it just lacks a new MVC module as an alternative to JSF.

In Java EE 8 such a new MVC framework is indeed coming. From the same startup
the article uses as an example:
[https://mvc.zeef.com/manfred.riem](https://mvc.zeef.com/manfred.riem)

That page is from the MVC 1.0 spec lead (Manfred Riem). It's going to be
strongly based on JAX-RS and mimicking how Spring MVC and Jersey MVC now
works.

~~~
stephen
Personally, I think "blessing" UI frameworks as JSRs ("official!") is a bad
idea.

I think it leads to the UI framework (e.g. JSF in the past or this new MVC
spec) "winning" and getting adopted by teams who, if they had to evaluate
several competing non-blessed frameworks, would pick something
better/easier/more modern, but instead go with the JSR-backed option.

Although perhaps I'm just being pessimistic. JSRs can probably be a good
thing; as a programmer in the JVM ecosystem, I've just never considered "it's
a JSR" as a brand of quality/something that should affect my choice, and if
anything it's the opposite.

(My pessimism aside, if they're basing the spec on existing good ideas, like
JPA did for Hibernate, and JSR-310 did for Joda time, that is at least a smart
approach.)

------
smoyer
We're (re)developing almost all our infrastructure in modern Java EE (as
layers of microservices). We're seeing less than 2mS response time for most
services and can afford to stack quite a few to build our customer facing
applications.

Ignoring the business logic, a RESTful API can be built to run on a Java EE
application server in about 10 lines of code. And it will run on any Java EE
6-7 compliant server implementation (as a single JAX-RS application ... you'll
need Java EE 7 for multiple JAX-RS applications per context).

EDIT:

I also should have pointed out that the "XML Hell" that was required to
configure applications and almost every managed object in J2EE <= 4 has been
eliminated. When the default behavior isn't quite what you want, meta-
programming can be accomplished with an annotation in the code. The few
remaining XML files can often be left empty - they're simply markers that
activate features of the server (CDI bean scanning, Java Server Faces, etc).

~~~
616c
Excellent timing. So I have played most of the time since college in Python,
bash, Perl, and very little Ruby (in that order). I am going back to school to
Java as part of my "torture yourself with the basics you blew off" undergrad
career that was not CS, and now had a change of heart.

I have seen in /r/java and Reddit and elsewhere people eschew even for newbies
the use of Spring Boot, Ninja, Dropwizard in company. Some like you say Java
EE is very friendly and I can write a full-featured REST service in like a
dozen or so lines of Java. Seeing as I wrote small pieces of homework
"employee ID insertion into memory" classes in like 100-200 lines, can you
show me said examples? Hyperbole or not, I would love to see good articles
about building REST services and other stuff in pure Java EE and/or JAX-RS
style explaining how a Java newbie can do this stuff.

I think other novates would greatly appreciate. The expanse of Java web
libraries is so vast even showing the minimalist modern style I am jealous of
in your post would be a huge benefit to me.

UPDATE: Oh Jesus Christ! Now I remember why the name Zeef seemed familiar. You
make that one of the few tutorial sites I found. Now, I will go crawl under
the HN couch while onlookers stare and surpress chuckles. Always read the
articles, dammit! Or meet me under the couch, rather.

------
cies
Is this article telling the story of someone who's been on the JEE for 12
years, loves it, and would certainly choose it again.

While I'm happy for him, I dont think it makes a good case JEE as a "startup's
secret weapon" (SSW).

By hypothetical comparison, if someone used 6 major tool chains for the last
$DOUBLE_DIGIT_NUMBER years, and by comparison says one particular tool chain
is an SSW, then I'm much more inclined to value the recommendation.

~~~
mikehaggard
I agree with what you say. Certainly would have had a bit more value if the
article had elaborated on whether they used anything else. I feel the
interviewer should have asked about that. Even a "no, we didn't" would have
been valuable. Now we know nothing.

That said, it DOES mean that they have been happy with Java EE and have been
so happy that they choose it again for their latest startup.

Contrast this with a typical startup where engineers always seem to hate
whatever they used before and are like children in a candy shop for having the
opportunity to use whatever we think is cool here.

~~~
cies
> That said, it DOES mean that they have been happy with Java EE

Sure. I'm also happy for them, and I acknowledge JEE's massive installed-base
and performance.

Just the "startup secret weapon" claim/title I thought was unfounded.

~~~
john-waterwood
I hear you. I personally stand by the title choice because IMHO there are two
facets to Java EE. I'm not saying that it's a fact (I simply don't have the
data to back it up), but those 2 facets I see are:

* huge installed enterprise base

* modernisation of the platform aiming it a both small and big users

I've been active in Java/Java EE for some time, and I know that these facets
can be at odds with each other.

For instance Java EE people wanting to support enterprises exclusively still
think in needs of enterprises, which means there's always a dedicated ops
team, an installed server that nobody but ops can touch and developers that
communicate with ops via tickets.

This warrants having data sources and security modules configured outside the
application and maintained by ops.

For small users this is silly overhead. When you're the only one developing an
app the security module can be right inside the app.

Some Java EE people have introduced mechanisms to do so, but the enterprise
people who are still there hate it, saying a server should always be
maintained by an ops team. The very idea that a small shop doesn't have an ops
team just doesn't occur to them.

Long story, but the simplifications that are making Java EE incresingly
suitable for small shops and startups, while maintaining access to the power
of the full platform to me doesn't seem well known yet.

~~~
cies
I respect your views totally. But I still disagree on the title.

> huge installed enterprise base

This is more a reason for a consulting shop to pick JEE.

All in all I think the article more describes why one cannot get around JEE
for enterprise work. And how JEE is not as terrible as it was.

That last point assumes levels of "terribleness" are well understood by by
many.

When it comes to "startup secret weapons" (except maybe for startups that have
to tie in with enterprise systems), I think JEE is the last thing that comes
to my mind. Even after reading the article.

~~~
john-waterwood
We're all free to have our opinions ;)

About the reason for the consulting shop to pick EE because of the installed
base, that was indeed my point regarding the first facet.

The first facet (huge base) is what appeals to enterprises. The second facet
(modernisation & aimed at small users) is what appeals to startups.

That EE had a huge installed base is pretty well known I think. But that EE
now also aims at small shops? Perhaps not so much ;)

------
mark_l_watson
That was a good interview. A few years ago, I took almost a year out to help a
friend (from since we were little kids) and his company and they were a J2EE
shop for the server side. One of the first things I did was to buy one of Adam
Bien's J2EE books because I had not touched J2EE for years. My friend is a
true Java Ninja and his architecture and code were elegant. That said, for my
own stuff I like the simplicity of Clojure and Compojure :-)

I looked at zeef.com and it is an interesting idea, but I tried searching for
a few broad topics that I am an expert in and found the results so-so.
zeef.com needs a larger number of human experts contributing.

------
paukiatwee
When HN comment mention how bad is "J2EE", I start to know the it refer to old
J2EE (J2EE 1.4 (November 11, 2003)). Now is JEE 7, no more J2EE!

Yes, JEE/Java is bad but please, there is no perfect framework/language.
Ruby/Python/NodeJS whatever is awesome, but it does not mean that it is
perfect langauge either.

Now JEE 7 is awesome enough that you should stop mention _J2EE_.

Also, Java maintenance best backward comparability that I ever know. Anyone
want to discuss Python 2 vs Python 3 and Ruby 1.8 vs Ruby 2?

~~~
oldmanjay
it's funny to see the same defense over and over. no one said any other
framework is perfect, but JEE is design-by-committee crap mainly designed to
sell consulting hours. that lack of external perfection does not make JEE
usable or worthwhile.

~~~
henk53
>JEE is design-by-committee crap mainly designed to sell consulting hours.

To whom does Geronimo sell consulting hours?

The design-by-committee hasn't been the case for at least 10 years. J2EE 1.4
was the last version largely developed that way. The last released version (EE
7) and the current one (EE 8) sees a lot of community contributions.

People from the community create JIRA issues, send contributions, even
implement entire features (see the work for JSF 2.3 and MVC 1.0).

If that's design-by-committee then everything is design-by-committee.

------
johnyzee
For rich web applications, GWT is a great option. It is a blessing to write
the frontend with the same language and toolchain as the backend, re-using
domain classes and constants across the projects.

Our current project uses Spring MVC for the backend, exposing REST services,
and GWT for the frontend, with Resty for marshalling data structures back and
forth. It works really well.

~~~
Ygor
How do you feel about improvements in GWT development speed? In terms of
development mode, compilation times and the whole process of making a java
code change and seeing the result in a browser? Is there a lot of work on
making this better?

GWT is nice, but I remember a lot of frustration came from buggy dev modes and
compilation times.

~~~
stephen
We've been using GWT master with both incremental compilation + Java 8 lambdas
(!) and it's pretty fun.

Granted, the non-JVM debugging experience is not nearly as magical as it was
before, but I believe there is some work afoot to merge SDBG (source map-based
debugging in Eclipse) + the GWT plugin. Still WIP.

------
devonkim
Seems like people are upset that they didn't compare JEE to common frameworks
and platforms that startups are known to use often like node.js w/ Express,
Ruby on Rails, and Django rather than trying to explain more of what's
interesting about modern JEE.

------
jincheker
Try other frameworks like Play, Spring,before you are confident to speak out
the word "productive", try other frameworks from other languages like Rails
before you are confident about start up speed

~~~
john-waterwood
I tried rails once. Startup was fast, but after 3 months we got stuck and
things weren't so fast anymore.

Modern Java EE let's you start about as fast as rails, especially when
starting from a good Maven archetype. The code is immensely simplified. I got
a backend service with JAX-RS and CDI running in literally no time!

------
threeseed
There is no doubt this combination would be extremely high performant e.g.
Wildfly was always in the top handful on Techempower benchmarks. But using JSF
and EJB is a pretty extraordinary combination to be using these days. You
would honestly be laughed out of every Java development team for even
considering it.

Would definitely like to see why something like Dropwizard, Vert.x or even
Play 1 wasn't considered.

~~~
john-waterwood
JSF and EJB are the reason why Java EE is lately considered the "secret
weapon".

The fact is that both invoke memories of old times where they were very
heavyweight and problematic technologies.

EJB was a total disaster, where you needed to implement 3 interfaces and
inherit from a framework provided base class, compile your code with a special
"enhancing" tool and run yet another tool to generate something called stubs
and skeletons, just to do hello world.

Modern EJB on the other hand is a POJO with a single annotation:

    
    
        @Stateless
        public class Bean {
            // do something 
        }
    

That's all. There are no required framework or business interfaces, no
obligation to put ejb beans in a separate EJB module and there are no specific
compiler tools needed. It's a total day and night difference.

In modern Java EE there's no reason whatsoever to avoid EJB.

There's a similar story with JSF. The first versions (1.x) were mostly POST
focused, had heavy session space requirements, and components were hard to
create.

In modern JSF 2.x, there's first class support for using GET, and the PRG
pattern is at the heart of interactions that are logically POST. Session
requiremebts are largely minimized by use of a partial state saving (only
changes to state are saved) and a stateless mode (nothing is saved). You can
use plain html to author pages with a single extra namespaced attribute to
mark it as a component to JSF.

Again a night and day difference and no need to avoid it anymore.

Then JSF has a number of very cool extensions available such as PrimeFaces
(beautiful visual components) and OmniFaces (Swiss army knife like Guave is
for plain Java)

~~~
hibikir
The fact that people that have used Java do not realize that EJB3 is pretty
good, when it's pretty old! I switched to EJB3 in 2006, and I really couldn't
see why people would choose Spring anything instead. The switch to Soap, and
then to Rest, was changing a couple of annotations. Not bad for a 9 year old
framework.

Now, my biggest problem with the stack, and the reason I do not use it
anymore, is Java itself. A switch to Scala makes a lot of the Java boilerplate
go away, and even Java 8 doesn't get close. Now, I find all the major Scala
web libraries to be lacking, in one form or another. Play's second compilation
feels clumsy. Spray's freedom of routing leads to very ugly code: Just look at
their own large examples. So what I am currently doing is using a homebrew
routing on top of Spray, which also gives me some documentation for free:
Pretty useful when you have hundreds of services in hundreds of servers.

It's a pity that Java itself moves so slowly, and is so reluctant from adding
key features, like pattern matching, because the rest of the tooling is pretty
good.

~~~
needusername
> I really couldn't see why people would choose Spring anything instead

Testing. Updates and fixes not tied to server releases (which can take years).

~~~
john-waterwood
Fixes don't take years with Java EE!!!

We're using JBoss and there's an updated version mostly every few weeks,
months at most. Absolutely not years, that's totally ridiculous and tells me
you've never really used Java EE.

~~~
needusername
JBoss still doesn't have a supported Java EE 7 server. JBoss releases still
much less frequently than Spring. If you want to look at how quickly things
are fixed in JBoss have a look at this:
[https://issues.jboss.org/browse/SECURITY-746](https://issues.jboss.org/browse/SECURITY-746)

If you need a feature in Java EE you have to wait several years for the next
Java EE release and several years more for the next server release that
implements this, see JBoss.

~~~
john-waterwood
You're mixing up things.

JBoss releases updates to its implementation rather frequently. If you look at
their release dates it's almost every other month. See
ftp://ftp.redhat.com/redhat/jbeap/

You're quoting an individual bug that has been open for some time. Did you
also looked at the many bugs that were fixed after a few hours after being
reported? Do you dare to state that Spring has no bugs or that none of their
bugs is open for more than a day, week, month?

Java EE has a spec cycle of about 2 to 3 years (there was an article about
this recently, Google it if you want). That's the time between 2 spec
releases. It's about the same time as between major supported JBoss releases,
so between EAP 5, 6 and 7. There's 3 to 4 years between major Spring releases
(Spring 2 2006, Spring 3 2009, Spring 4 2013).

And Java SE doesn't release a major new version montly, let alone yearly
either. A spec should move fast enough to stay relevant, but slow enough to
provide the stability needed so lots of other technology can build on it.

~~~
needusername
> JBoss releases updates to its implementation rather frequently. If you look
> at their release dates it's almost every other month. See
> ftp://ftp.redhat.com/redhat/jbeap/

[http://jbossas.jboss.org/downloads](http://jbossas.jboss.org/downloads)

EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months

> Do you dare to state that Spring has no bugs or that none of their bugs is
> open for more than a day, week, month?

In about 50% of the times I have reported bugs or submitted pull requests
against Spring they were closed within 6 hours. Spring releases about a month
apart. The other 50% lay dormant for years. Still way better than any
contribution I tried to make so far to Java EE. 0% success in about 6 tries.

> Java EE has a spec cycle of about 2 to 3 years (there was an article about
> this recently, Google it if you want).

[https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edit...](https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition)

Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5: 3
years

~~~
john-waterwood
>EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months

That's skipping a lot of updates. EAP 6.2.2: 1 month EAP 6.2.3: 2 months EAP
6.2.4 1 month EAP EAP 6.3.0: 1.5 months Etc

>The other 50% lay dormant for years

So this exactly the same as with a Java EE implementation or any other open
source project for that matter. Many get fixed in hours, others weeks or
months and some years or simply never. Spring is not inherently better here as
their track record proves. That your personal reports were of no success maybe
says more about yourself than of any Java EE implementation. I got many bugs
fixed and have seen others reporting bugs that have been fixed in no time.

>Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5:
3 years

I was more referring to this one: [http://arjan-
tijms.omnifaces.org/2014/10/java-ee-process-cyc...](http://arjan-
tijms.omnifaces.org/2014/10/java-ee-process-cycles-and-server.html)

The actual time spend on the spec is less (see table). Whatever number you
look at, it's not that different from the major Spring releases, and Spring is
a product even, not a spec.

~~~
needusername
> Whatever number you look at, it's not that different from the major Spring
> releases, and Spring is a product even, not a spec.

Spring releases are every month. When there is a bug in a Java EE spec (like
the WebSocket/CDI integration or the CDI annotation scanning in EE 7) you have
to wait for the next major spec version to fix it. The spec has to be
"perfect" for 3 to 4 years because there is no way to fix it.

~~~
henk53
>The spec has to be "perfect" for 3 to 4 years because there is no way to fix
it.

This is absolutely not true.

There's the MR (Maintenance Release) for that. See for example JSF 2.1 and CDI
1.2. They were intermediate quick releases between major Java EE versions.

Even the platform spec itself can have a MR. Currently there's an MR for Java
EE 7 in the works. See [https://java.net/downloads/javaee-
spec/JavaEE_7_Platform_MR_...](https://java.net/downloads/javaee-
spec/JavaEE_7_Platform_MR_Candidate.pdf)

Because it's a spec, naturally more consideration has to go into it. Many
implementations depend on it to be stable. In case of Spring there's only one
Spring. Take it or leave it. Not having a spec behind you can be an advantage
(change things whenever you want), but is a disadvantage as well (the implicit
specification of how things work is in the code, but Java is not declarative
and it's always a guess if specific behavior is just an implementation side-
effect or an intended one).

Even changing things whenever you want can be a disadvantage. A spec naturally
favors stability, which means I can run my old code with minimal or no changes
at modern Java EE. Try that for regular open source libraries (be it from
within the Java EE universe, Spring universe, or whatever). Chances are that
the APIs and config files have changed 10 tens in the meantime.

------
bni
From the article:

"So our strategy has been to reduce the number of relations between entities
to what is strictly necessary, and occasionally to use JPA DTOs when a subset
of data is needed for a rather complex entity. Such DTOs are populated using
the constructor selector syntax in JPQL queries and JPA is generally smart
enough to generate far more optimal queries then."

I have been using this "pattern" a lot lately, its great. looks something like
this:

SELECT NEW mypackage.Pojo( e.id, oe.name ) FROM MyEntity e JOIN e.otherEntity
oe WHERE e.someProperty = :parameter1

Its also possible to place these in external files, working around Javas
inability to have multi line strings after all these years.

------
CoffeeDregs
Perhaps OT: I often swing by Java web/services frameworks every year or so and
I never see a good DB migration/evolution story. I'm fairly certain that it's
because I don't know where to look or that I'm thinking about it incorrectly,
but I've yet to see a Java web/services framework that supports the easy
database migration/evolution schemes of Django/South or of Rails. Are these
migration schemes not supported for a reason? Or am I missing the docs?

~~~
stephen
I imagine most Java web/services would consider it bad style/coupling to pick
just one data back end (e.g. assume everyone uses JPA or Hibernate or what
not), which would be needed to support migrations.

Even after Rails, the Java ecosystem is less "everything out of the box" and
more "build your own stack". There are some exceptions, e.g. Grails and Play.
Although both of those have migration modules:

[https://www.playframework.com/modules/migrate-1.3.2/home](https://www.playframework.com/modules/migrate-1.3.2/home)

[https://grails.org/plugin/database-
migration](https://grails.org/plugin/database-migration)

(First hits from Google, so apologies if those aren't the latest/best
results.)

And, even then, I think both Grails/Play also try to be backend-agnostic, e.g.
the migrations being plugins instead of first-class/backed in, like Rails
which assumes "yeah, you'll basically always use a relational db".

Also, re migrations, a shameless plug for my ORM that relies on migrations+the
database schema to codegen the rest of the boilerplate:
[http://joist.ws/](http://joist.ws/).

------
puppetmaster3
I hate to tell you all since none will thank me, but the horse has left the
barn - we now have 'thick client' where the app is client side in .js.

Also consider APIs/Baas: Backendless.com, Kinvery, App42, etc.
[http://baas.apievangelist.com](http://baas.apievangelist.com). DIY REST is
purely optional, for companies w/ poor CTO/CFO. PHP, JSP, ASP, Rails, Django
is in same boat, server side rendering of UI is past prime, we now need
stunning UI, ex: datatables.net, Admin LTE, etc.

Framework today is UI Kit, BootStrap, Foundation, etc. That is a framework.
Alternative to that is PhoneGap, Swift - and for Java, there is hope, in
Android.

~~~
blumkvist
I read somewhere that the best troll comments are ones where you can't tell if
the poster actually means what he says or is trolling.

------
edem
I can imagine that they feel themselves productive with EJB but only without
the contrast say Ruby, Python or LISP would give.

~~~
edwinnathaniel
Choosing Java over Ruby/Python for your web-app really depends on what you
want to sacrifice.

I counted LISP out because unless you're using Clojure, I know for sure you're
not going to be able to beat anything else for web-app development. LISP for
web-app probably works in the 90's for PG but we're in 2015 where libraries,
frameworks, and tools for these other languages are just far too advanced and
more productive than writing macros... sorry mate.

Anyway, back to Java over Ruby/Python.

Take a few examples:

At the Microservice area, Java seems to shine over other languages/platforms.
JAX-RS feels more complete than Sinatra or whatever Django plugins that the
Python community use. See a quick example of JAX-RS vs Sinatra somewhere in
this blog post: ([http://www.appneta.com/blog/microservice-service-oriented-
ar...](http://www.appneta.com/blog/microservice-service-oriented-
architecture/))

Maven can be huge and underwhelming (and ugly once in a while) but it's
definitely more powerful than gems+bundler+rake and whatever Python adopts
these days. Maven has been around for a while so most Java DEVs don't have to
pick up tools as Python DEVs have to do quite often. But again, there are
trade-offs: Maven XML is definitely uglier than Bundler or requirements.txt or
package.json.

Let me ask one thing: in platform other than Java, do you use declarative
transaction? My guess is "No". Which means you have to know when to open and
close a transaction (and potentially join an existing one if the library isn't
smart enough). Java Spring/EJB provides annotation based transaction.

I'm not suggesting that Java is better than other languages, but there are
advantages of choosing Java.

~~~
edem
Clojure is a LISP and from my experience I'm way faster with Clojure than with
Java. Plus Clojure can use any java library. And by the way it seems that you
have never used any lisp for web development. When you bump into the first
problem with the bloatware made of 30.000 files and you have to debug it
because there were no answers on stackoverflow...then you will find all out
about the dark sides of "advanced frameworks".

------
dschiptsov
Please, Java EE here is an offence to our intelligence. There are infoq and
other yellow paid content sites for it. Please.

~~~
mkawia
What's wrong if that platform is improving . There are so many really good
java libraries to play with .

I for instance wanted to build a webapp with the StanfordNLP .

~~~
dschiptsov
Oh, come on, the creator of this site has a whole essay about languages (or
platforms) which has been made to solve actual problems faced by its creators
or to solve other people's problems (to be sold to greater fools). There is no
better example of second approach than J2EE.

To Google J2EE sucks is not that difficult. My favourite quote from Bell Labs
folks - "whole encyclopedia could be written about what is wrong with J2EE".
Rebranding doesn't matter - it is the same crappy mess of piles of unnecessary
layes of ugly, redundant abstractions.

Don't be hypocrites. It sucks.

~~~
speakeron
> it is the same crappy mess of piles of unnecessary layes of ugly, redundant
> abstractions.

This is straw-man stuff based on an old view of who uses Java and when.

I've programmed in a lot of languages - C++, Java, Objective-C (with a NeXT,
of course) and the trendier functional, meta-programming languages.

One of the cliches (and truisms) of C++ is that you only use a subset. This is
what people are doing with Java these days. You can bring up high-performance
web services using only a thin layer of J2EE and throw away all that cruft you
mention. In my company we do it all with a third-party web layer and just SE
(is it just J2EE you're agin - are you fine with SE?).

What Java brings to the table is a well-sorted high performance JVM, copious
free and high-quality third-party libraries and a clear and easy to use
syntax. Yea, it's quite verbose, but, as you know, you spend more time reading
code than writing it...

~~~
dschiptsov
OK. This your choice and your conditionig.

I, if you allow me, would still hold an opinion that web services could be
made without "everything is an object" meme or "static typing which catches
errors". There are Arc and Erlang and even Common Lisp based solutions.

Also I would argue that Golang is a much better alternative, which has been
creayed, in part, because J2EE sucks.

Straw man or whatever you would call it.

~~~
henk53
> because J2EE sucks

It does, but Java EE is great! :)

