Sunday, July 24, 2011

Stop hating Java 2

This post is in response to Andrzej on Software/ Stop hating Java post. I support most of the ideas Andrzej expressed in that post. Think of this post as continuation. This is my brain dump on things that was sitting somewhere in the back of my mind for some time and Andrzej's post jolted it out.

Ruby developers are prone to cults (observation).
It is interesting to see that Ruby developers (most people I worked with are good smart guys)  seem to have all drank several cool-aids: Ruby/Rails/Apple MBPs/IPhones/TextMate. They are "green", look to be "democratic", wear sloppy clothes, and are "laid back". They certainly fall into a few stereotypical descriptions. They religiously follow another big gorilla (Apple), whose policies are even more tight than that of Microsoft. What is more interesting is that we were able to pinpoint a Ruby developer in a group photo shot! Overall, I'd say because Ruby developers are prone to cult-like behavior, they miss a bigger picture sometimes. For them if it is not Ruby, it must be crap. Ruby developers are sometimes categorical to the extend bordering adolescent behavior. I think it is generally a human thing to resists other peoples' opinions and change. (note to self: Ruby developers are humans :)).

Any platform will do
Most people dislike languages they do not use, and Ruby developers are not exception. However, any language/platform can be used to build excellent piece of software, and there are many examples of that. Most all (as someone mentioned on Andrzej's post comments) think that PHP is crap, but although I'm not a PHP developer, I enjoyed this post from MailChimp, who has proven that if you have a brain you can build a great system ... even in PHP:) - http://blog.mailchimp.com/ewww-you-use-php/

How Java screwed up royally
  • Standards - the biggest flop in the Java history was Java Enterprise. This does not require any explanation, I hope. Standards are a plague of Java. They are designed to make different implementations together, but this is not happening. Instead, they take years to "standardize", when Internet years are even shorter than dog years. There is a handful of low level good standards: JDBC, Servlets, JMS, but the rest is just a waste of time.
  • Trying to circumvent standards - Spring/XML mess. Spring came to mass market some time  in 2003, and spread like wild fire (due to complexity of JEE). I personally do not like Spring and try to avoid it at all costs (same goes for JEE). Spring projects are messy, impossible to debug, and tend to grow like a cactus: in all directions.
  • Way of thinking that if you have a hammer(Spring/XML) in your hand, every problem looks like a nail (your project).
  • Popularity of Java sucked a lot of people into the Java world who should not be there (maybe they should not even be in IT in general). I'd argue that when (if ever) Ruby becomes as popular, it will get all the problems Java has: boring business applications, millions of lines of unmaintainable legacy code, army of non-talented and non-passionate developers, corporate culture,  heavy management, etc.
  • Java developers are ostriches - they keep their heads in the Java sand and are afraid to look around.
Ruby would be in obscurity if not for Rails
Ruby developers say they have things other than Rails. I'd say this is BS. All things non-Rails came about to support Rails in one form or another. I think that Rails undoubtedly made Ruby famous. Rails is a Ruby killer application. Ruby is actually older than Java by a year or two, but has been in obscurity all these years until Rails came along. If it were possible to predict a different past, I'd say that if DHH used PHP for his projects and never wrote Rails, the world as we know it would associate the word ruby with a precious stone, rather than a programming language.

My History of Rails experience
I worked on a website project for Sears that was all Java, but slowly became a blend of Java and Rails. When this was happening, the project was joined by a number of good Ruby developers. While we had disagreements and arguments, I adopted a strategy to learn as much as I could from these folks, and about Ruby/Rails thing. As it turned out, there was much to learn and so I did. In the process, I also saw that many good things in Rails can certainly be implemented in Java, to the benefit of Java community.

What I did to make Java developers happier
Needless to say, I like Rails for its productivity and think that the Rails way of conventions and style of web development is(was) better than anything I knew in Java. So, I waited for someone to do cross-pollination and implement these ideas in Java. And then I waited some more. After a 2 - 3 year wait, I realized this is not happening, and decided to take the initiative in my hands. I wrote JSpec with DSL similar that of  RSpec, ActiveJDBC - implementation of ActiveRecord in Java, and ActiveWeb - dynamic web framework similar to Rails. I manage a team of 10  developers and we have a mixed environment Rails/ActiveWeb/ActiveJDBC and about 10 commercial websites/batch applications. All new sites are built with Active* stuff, and I can attest that developer productivity in Java are the same as using Rails.

What I seriously miss in Java
Closures! Of all the stupid useless language features that Sun has been adding for years (generics for instance - only a madman can understand their syntax), they
missed the boat with closures, the one and only feature I genuinely miss. Closures certainly would make all the callbacks and stupid inner anonymous  classes go away - and this will be the biggest contribution to making Java more readable. IN addition, closures would make most Java APIs concise and easy to use, as Groovy has already done by adding a ton of methods to JDK classes.

Message to haters
It seems that people who start sentences with: "I hate..." have constipation or something. My advice: take some Metamucil, after that a few beers with friends, and then surprise people you know by always starting with: "I like ...".

Conclusion
Whew, if you are reading this sentence, you are one patient person! All these Java vs Ruby vs .NET vs PHP [plug your abbreviation here] discussions are water under bridge. People call Java Cobol of the day. I'd say that if a Java program runs a business for 30 - 40 years, it is a huge success. Who knows what languages we will be using 30 - 40 years from now? So far, we have a good selection, let's enjoy!

25 comments:

pdimitar said...

Excellent article. I especially appreciate your being honest to the all sides.

As much as I love Ruby (and I did work 7+ years with Java, Ruby 1 and a half year now), I do agree the Ruby community has some flaws to polish, too -- the recent bundler/Rake fiasco being especially bright example.

Thank you for being so objective, I really did enjoy reading this article.

Lukas Eder said...

Hi Igor,

So I'm going to make the start by saying "I like your post" :-)

While I don't agree on the importance and usefulness of Java 5 Generics (but then again, maybe I am that madman), I'm also looking forward to Java 8 Project Lambda, like you are.

I didn't know that you had other Active* projects, apart from ActiveJDBC. We've "met" on your user group, recently, when I was comparing your ActiveJDBC with my jOOQ (http://www.jooq.org). It's nice to see that we share similar beliefs behind our attempts to create non-standard tools to improve user productivity. So in that sense (as the jOOQ developer), why don't you add JPA's Criteria Query API to the list of horrible mistakes, that Java has made? I think it's the king example of JEE gone wrong (right after EJB, of course).

Cheers
And thanks for that inspiring post! :-)

Lukas

Igor Polevoy said...

Lukas, welcome back again.

My reaction to generics comes from working on AJ. Generics is a nice feature, but syntax can only be understood in simple cases. When things get complicated (as in AJ), syntax becomes hard to comprehend.
Agree on JPA Criteria (avoided like plague), but there are so many things that can be added to the list...

cheers

opensas said...

well, after developing ActiveJDBC and ActiveWeb, I'd certainly would like to know your opinion about playframework...
I think that, so far now, is the closest thing I've found in the java world that resembles rails productivity, without being a mere port of rails...

opensas said...

well, after developing ActiveJDBC and ActiveWeb, I'd certainly would like to know your opinion about playframework...
I think that, so far now, is the closest thing I've found in the java world that resembles rails productivity, without being a mere port of rails...

Igor Polevoy said...

Opensas, I was expecting this question :).
I think that Play! is a great framework. I started working on ActiveJDBC in 2009, well before Play! came out. I had simple ActiveWeb prototypes in late 2009, but started serious development in spring of 2010. That is when I learned of Play and was shocked at first how similar they are. At the time I was considering dropping AW development all together, but after a careful examination of Play!, I(and my team) concluded that there are significant differences too, and I continued development. The major differences are:
* Play has a nice ActiveRecord-like abstraction, but the underlying ORM is still JPA/Hibernate. I dislike Hibernate for its massiveness and strange behavior. The Play! JPA layer is baked into Play and cannot be used outside. ActiveJDBC by contrast is a general purpose ORM written from scratch, its underlying technology is ... well JDBC. It is super small, fast and has no dependencies, can be used in any situation and is not tied to ActiveWeb.
* The Web layer. Play guys developed it based on a standalone web container - Netty, and developed new API, which is not Serlvet - based. As a result, they have a nice share nothing architecture. They have blogged about this decision, and it is pretty cool. Play can even be wrapped into a WAR file and dropped onto a JEE container. However, since this is a share nothing, non-Servlet architecture, it cannot communicate with other Servlets. This means for one thing that you will not be able to slowly blend Play into an existing web app. ActiveWeb is a Servlet Filter, and as a result you can drop it into any existing Java Web application unrestricted. If you do not want to share anything across requests, just do not stick anything into a session, but if you need a session, it is there for you. After all, any container can be configured to keep session data in a DB, effectively making your application "share nothing".
* Build. Play comes with a set of nice Python scripts (btw, why python? I'd expect Groovy for a Java project:)) for building, and other things, and has its own project structure, much like Rails. ActiveWeb is a Maven project and has a standard Maven structure for a web app. While Play has plugins, ActiveWeb can enjoy just about anything under sun for Java web app, or selection of hundreds/thousands Maven plugins to do anything. ActiveWeb plays Java standards, and as a result, is easily deployable as a EAR module, can send JMS messages, call EJBs, in other words, participate in a Java ecosystem as any other Java Web technology.

All this (and a bunch of other things I'm not mentioning) gave me enough inspiration to continue work on ActiveWeb.

whew, sorry for lengthy reply, thanks for reading this

Lukas Eder said...

Those are interesting thoughts about the Play! Framework. I wasn't aware of its tight coupling to JPA. Maybe that can be circumvented in some way.

Since you're at it, what do you think about Wicket? Wicket is much more mature than Play! but at the same time not as sexy anymore. Have you made any experience with Wicket (which also prefers convention over configuration)?

Igor Polevoy said...

Lukas, the Wicket API does not strike me as appropriate for web applications. Web applications are not OO, they are request/response. It is hard to convey this thought actually. Basically having an object behind a page seems strange to me. In addition, Wicket is not a full stack framework, testing part seems tiny, convoluted and built as afterthought. By contrast testing in ActiveWeb was build from ground up, just look at this:
http://code.google.com/p/activeweb/source/browse/trunk/activeweb-simple/src/test/java/app/controllers/BooksControllerSpec.java
This code will run a controller, generate view, etc. and will not require a container.

However, I might be unfair to Wicket, since I never actually used it. It just does not feel right to me.

Lukas Eder said...

Hmm, good point about Wicket trying to be OO. But I don't know the implications of that either. I haven't heard a lot of bad things about Wicket, though. On Stack Overflow, the two frameworks are about equally popular:

http://stackoverflow.com/questions/tagged/wicket
http://stackoverflow.com/questions/tagged/playframework

So you've made good experience with testing the controller directly with Java? Do you also run integration test suites with Selenium (or a similar tool)?

I'm wondering about these things because I want to start integrating jOOQ in existing web frameworks, and so far, Play! Framework seemed the one with the most traction. But ActiveWeb might be a good showcase, too. Are you planning to do more marketing for ActiveWeb, now that you've decided to keep it alive next to Play?

Igor Polevoy said...

yes, ActiveWeb has been around my work environment for over a year now, in production, but the documentation is lagging. However, I will be doing a presentation on it for the CJUG (Chicago Java User Group) on August 16th, and I will (have to :)) complete all documents currently outlined in the TOC on the site. I'm not good at marketing unfortunately, but I think it will start getting traction once the docs are out and I start blogging/posting links on sites about it.
I think it is different enough so as to make people interested in it.
If you decide to integrate jOOQ with ActiveWeb, I will help guide you to the right places in code.

cheers,
igor

Igor Polevoy said...

sorry, integration tests in ActiveWeb is ability to describe a scenario of a web flow - submit a form, then go to a different controller, call some action, verify data in DB, check structure of html, check response code from controllers, check content type, etc. All this can be done in a single (or many) JUnit test without a container (works like regular Java code, really fast). I call that integration tests.

Selenium tests are "user acceptance tests". ActiveWeb has no built in support for them. What we do here is create Selenuim scripts as a separate project and run it on Hudson on schedule. It hits our test server with deployed application, and if fails, sends emails.

thanks
igor

Lukas Eder said...

Thanks, Igor. I'm surely interested already, and I'll happily get back to you for guidance, once an ActiveWeb integration will be done!

Cheers
Lukas

Bogdan Marian said...

Though I am but a mere developer (Java and .NET), I must say that during my Java development years I have found out that J2EE (1.4) has been transformed to JEE (5 and then 6) and web applications got a lot more easier to develop. EJB 3.1 is very easy to use. You got CDI which includes conversations, a very nice and useful feature. There are a lot of JSF component frameworks out there, like PrimeFaces, RichFaces and so on, which allow creation of very stylish and nice web apps. If you do not like JPA 2 with Criteria API (which for me is indeed a mystery as I always have to google for a simple query like "select * from ..."). you can use QueryDSL. What I really like about Java is the plethora of options. You are not bind to anything, you can choose what you like... Of course, having thousands of web app frameworks makes choosing difficult, but just imagine you would only have one option (as we did in .NET world, struggling years with ASP.NET Web Forms). I have seen the emerge of lightweight frameworks so things are pretty interesting again in Java (and .NET).

Oronno said...

Interesting post.
Well... I am a little bit curious by seeing your hatred on "Spring/XML" terms.
When did you last tried on Spring?
Do you ever tried Spring 3.X (what comes with Annotation most of all)??
Anyway, Enjoyed your posting. ;)

opensas said...

thanks a lot for your detailed response!
now that you've taken your time to answer, you could add it to the documentation, a "comparing activeWeb to other frameworks" section or something like that
by the way, it would be nice if you could make a plugin to use ActiveJDBC with play. I don't know how deep are the JPA enhancements buried in play, but there are lots of plugins for other db backends...

saludos

sas

Igor Polevoy said...

Bogdan, you are correct, some of my comments might come across as too strong (I might fall into some of the categories I described above :)), but I have been boiling for too long. True that latest JEE is better of what it was with EJB 2, but.. and this is a BIG but.. the JEE evolved as a response to the needs of community instead of being a leader. Their response time was also pretty slow. As a result, I'd say that JEE 3.x is too little too late. Here is a deal breaker for me: can you create a JEE application and write a test so that:
1. You simulate a web request to web layer
2. Web layer calls EJB
3. Data changed in DB
4. Page gets rendered
after that you assert HTTP response code, check data in DB, validate structure and check values in generated HTML?
TDD/BDD has been around too long for excuses. If you cannot test your app, there is no way you know that it is working. TDD/BDD has become a MUST requirement, and lacking support for it is a deal breaker for me.
As far as JSF - this is a technology that came straight from 90s. While they have a spec, good luck mixing components from different frameworks on a page. Additionally, JSF is slow, and generates crappy HTML. Ask a decent HTML guy, to do a pixel perfect design of the JSF site, and he will quit.

Lukas Eder said...

I must agree on JSF. It's been horrible. The amount of memory and CPU power needed for running a small app... (with RichFaces)... And the number of hours debugging because someone didn't fully fully understand the JSF lifecycle (who can blame them).

I really hated JSF. I'm working with XSLT now, and having full control over HTML, CSS, JavaScript, etc is so much better.

Igor Polevoy said...

to oronno: Spring is a DI container, but it is trying to be God. There is a known anti-pattern God Class, in this case, I have discovered a new anti-pattern: God Framework. XML is a not a programming language, at best declarative. Binding components in XML leads to proliferation of XML files, one including the other for various purposes, all are hard to read. IMHO, annotations are even worse that that, since they are scattered across application. Back 10 - 12 years ago, I used DI pattern and I did not even know it. I'd write my code as POJOs, then write a single class called Bootstrap, where I'd use plain Java to create instances of POJOs and bind them together. While this was a primitive approach, it was so much easier to work with! I think that Google Guice is the right approach to injection API, this is why it is integrated into ActiveWeb

to opensas:
Not sure Play! needs ActiveJDBC. Their added API on top of JPA is pretty similar to AJ. Besides, my time is consumed by ActiveWeb. However, if someone want to do this, I will provide all help I can

thanks

igor

Rakesh Waghela said...

My 2 Cents,

RoR inspired frameworks in Java.

ActiveWeb/JDBC :-
-- Your creation
-- good to start
-- lacks docs on ActiveWeb
-- din't like instrumentation step
-- not known out side enthusiastic ppl like me,Lukas,opensas


Play ! :-
http://www.playframework.org/
-- Have accumulated big community
-- very active mailing list
-- Play has team of committers
-- Multiple companies are backing
-- good set of plugins
-- sucks at view layer

ScooterFramework.:-
http://www.scooterframework.com/
-- RoR's java mirror
-- pure standards based
-- very rich set of libs
-- a bit complex in configuration
-- good docs
-- one man show in development
-- not so frequent release
-- silent mailing list
-- not so known


My Ideal LibSet For Java Web Application Development with MVC
-- Play ! { For C Of MVC }
http://www.playframework.org/

-- JOOQ { For M Of MVC }
http://sourceforge.net/apps/trac/jooq

-- Cambridge { For Server Side V Of MVC }
http://code.google.com/p/cambridge/

-- JQuery+UI and For Ajax stealing idea from Scooter Framework
http://www.scooterframework.com/docs/ajax.html

-- resource service management in multi tenant saas app by making tool similar to DDSL using java/Hazelcast instead of scala/zookeeper

https://github.com/mbknor/ddsl

Phew.. :)

Igor Polevoy said...

sounds good, go for it :)
As far as ActiveWeb, documentation is coming up, and will be pretty much complete in two weeks time

Ron Smith said...

Igor,

Good points. If the language/framework/tool you're using is working for you, great. In the end it's about delivering an application that works well for your customer.

As far as Java, there are many extremely successful web sites based on the Java platform, and yes, the Java language. Not to mention its use in "traditional" businesses where it's dominant.

That's not to say there aren't things that annoy me about Java the language and there being room for improvement - there are. My biggest gripes are the lack of closures and to a lesser degree continuations and the general verbosity of the language.

That being said, if you choose your frameworks and libraries well, you can be extremely productive in Java. Declaring the types of those parameters and extra lines of code for anonymous inner classes aren't the giant productivity-killers some make them out to be. Static typing, excellent performance, rock-solid libraries, reliable database drivers for every database, and great developer tools are really nice to have too. Sometimes when troubleshooting database driver issues in Python, or working around the Python global interpreter lock, I missed those aspects of Java.

I'm hoping the development of Java the language will now be accelerated under Oracle. It seems the JCP process has slowed things down too much in the past, and they were overly conservative as far as backwards compatibility, in particular at the language level. Scala is a good example of the types of improvements that can be made while keeping the language statically typed.

sunil sanap said...

Excellent article. I especially appreciate your being honest to the all sides.

mvmn said...

Servlets aren't a particularly brilliant standard either.
Too much coupling between stuff (requests to context etc) make it hard to mock even basic things like requests and responses.
The bad practices of keeping stuff in one big map like page/request/session attributes, including container stuff like "javax.servlet.forward.request_uri" for forwards and similar for includes.
Lack of possibility to dynamically assign mappings to servlets (until Servlet 3.0, when it was already lagging behind Spring).

Not that servlets are bad, but all this could've been done better from the beginning or improved earlier.

Igor Polevoy said...

@mvmn, there is no limit to improvement, of course servlets could improve, but my point was that the basic Java APIs were designed right (JDBC, Servlets), while what followed (EJD, JSF)m killed productivity and turned many developers away from Java as a platform. While servlets aren't particularly pretty, they serve well. Think of them as army soldiers:) - not models, but always get the job done!

Igor Polevoy said...

I meant EJB, not EJD, sorry for typo