Hacker News new | past | comments | ask | show | jobs | submit login

I don't understand why this culture of making things ever more complicated has grown up around Java. I've given up using these trendy frameworks and make do with just Struts/Tiles and plain JSPs. I've recently rewritten an application that used Oracle ADF and it came out 10% the size of the original.

What I've found is that many IT departments feel pressured to use Java but don't really want to learn Java, so they try to find an IDE that will let them build the GUI without coding and a framework that will turn most of the job into configuration through XML. The result is that the solutions are a lot more complex and people hate Java.




But.. but... but... we're an Enterprise! Any language that doesn't require writing a Dao and a DaoImpl and a Service and a ServiceImpl and a Controller and a ControllerImpl and an extremely verbose JSP template and about a hundred lines of XML to do something trivial is a toy!

I don't care if YouTube scales to hundreds of millions of users with Python, our 200-user website is mission-critical and demands scalability!


The above comment describes everything I work with on a day to day basis at my job. Every solution contains multiple layers of abstraction from the aspx to the code behind, to a controller to multiple services to multiple daos and with all of them implementing something to allow for testing.

Except very little is tested (its getting better) and everything is so tightly coupled it dosnt make a difference anyway.


I once had to try and salvage something useful from a huge J2EE application where the development team were obviously as they say "taking the p*ss".

At one point I counted 23 layers of abstraction between the fairly simple JSP page through EJBs and a connector to eventually make a simple SOAP call to get the data to go on the page. Everyone of those layers had an interface, a factory and an implementation....


Some of the source code was missing too - so I had to decompile great chunks of stuff and wade through the resulting code to find out what was going on.

Imagine my delight when I found multiple jar files, all with the same name but with different contents, all included in the classpath for WebSphere.

Something like 98% of the code did nothing useful.


I don't understand why this culture of making things ever more complicated has grown up around Java.

I think it is because of the whole corporate ecosystem that surrounds it. There's experts that need to make a name for themselves, consultants that need to make money, companies that need to sell services or consultants, etc. etc.


Java is a fine language, but it has some significant limits. Unfortunately Java has become the de facto general purpose language in many places, especially in "the enterprise". So a lot of tools have been built in and on top of Java which allow you to do anything and everything with it, even when other languages would be a far more natural fit and would require drastically less development effort.

Worse yet, many dyed-in-the-wool javaists also have mental blinkers (see: blub language) which prevents them from seeing outside the limits of the language, leading them to believe that it's perfectly natural and normal for an MVC application to require mountains of code, mountains of XML, and every detail reproduced in exacting triplicate across the depth of the framework. Simply because they lack the perspective to realize that they're missing out.


> I don't understand why this culture of making things ever more complicated has grown up around Java.

Because nothing is more enterprisey than "architecture astronautics". Also, it's a nice way to spend time doing nothing useful in a large bureaucracy.


What about the fact that everything needs to be a class? This works on Javascript or Smalltalk, which are dynamic languages, but not in a static language.

There is no way to have a function callback mechanism without introducing new classes. The very culture of using design patterns for everything is just a reflection on how things are solved in Java.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: