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

> All that stuff makes it easier later to write more complex stuff

I sincerely doubt that. I've seen E-Banking systems run on Jetty with JDBC directly. No fancy JSRs were needed.

Btw: J2EE was indeed even more bloated than JavaEE. I don't think that anyone would defend J2EE nowadays, not even the folks behind JavaEE




> I sincerely doubt that. I've seen E-Banking systems run on Jetty with JDBC directly. No fancy JSRs were needed.

If you need distributed transactions (and sure, most people who think they do don't), you use the fancy JSRs or you will go out of business. That stuff is hard and it's the reason JEE is so horrible, but it solves problems you can't solve any other way.


Yep. I understand the use cases of JavaEE's JSRs. Yet, I personally don't see why I should install a complete 300MB application server (possibly with horrific licensing) just because I happen to need one of their JSRs in just one part of the application (that happens to need JMS because the customer's CIO was walked into buying expensive licenses from IBM), which is otherwise mostly just transforming data between the UI and the database. It's just a JSR and I'm glad to buy licenses from a commercial JSR implementor...


Making technical decisions for non-technical reasons is always bad, whether that's a decision to use a particular technology or a decision not to use a particular technology. I think many users do derive value from having an all-in-one platform that provides all the JSR implementations they need and they can then just forget about.


Truth be told, the code quality of electronic banking is often rather questionable. Probably they developed a prototype without any bells and whistles (and without proper guards against code injection, without support for distributed operation) and then were forced to use it as the base of the real product.


One another reason for loads of standardization in JEE is with performance and scalability guarantees which are not provided by developers but by application container vendors.

Writing an E-Banking application on JDBC is certainly possible , but do we write code to make performance guarantees,for transactional isolation,maintainability or do we only write code for the business we need to attend, this is the question that leads to JPA [or JEE] .

JEE stack does involve a steeper learning curve but is a different one indeed!


It's just an E-Banking system, i.e. the UI for the core-banking system, which is still written in PL/SQL and Delphi.

It has been working fine for many years with no differences between with or without J2EE.




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

Search: