I've also done some JEE quite a long time ago and I hated every second of it. I'm not sure however if my experience is representative of the the Java community. There is no problem with the language itself nor the VM which is also working quite fine (while taking a lot of RAM). But I really have a problem with the community, everything seems over-engineered and super complicated in Java, even with simple things.
Nothing works by default, you always have to include stuff here and there, write one or two xml files before anything would work, I'm fine with configuration but I should at least work by default. Maven is a nightmare to use, it's so complicated I would generally not use it. I would just like a package manager which is only doing packages like any other language.
The main problem with the Java community in my own opinion is they are building pyramids while other languages are building stuff out of bricks, it's the opposite of the UNIX philosophy.
> they are building pyramids while other languages are building stuff out of bricks
Pyramids are engineering feats, Java EE people are building stuff which look like works from M. C. Escher, it bends your mind when you try to understand the code :)
Also a little anecdote to the complexity of enterprise stuff: at the company I worked before, they were writing an entire persistence framework from scratch (with annotations instead of xml) so they could get away from hibernate.
Maven is wonderful. It's the opposite of complicated. You declare the artifactId, "groupId" and version of your project. You declare those same values for your dependencies. And then it Just Works. When you want to release, you invoke the release plugin, and it will do all the right things. If you want a test coverage analysis, you invoke a suitable plugin (e.g. emma) and it'll do the right things. It is, hands down, the best build system I have ever used, in any language.
The problem comes because everyone thinks their build is a special snowflake that absolutely needs to replace every instance of the number 15 in their codebase with a heart symbol. No. You don't do that. If you're doing something standard there will be a plugin for it. If there isn't, it's probably because what you want to do is a very bad idea - do it in code instead. If you absolutely insist, you're going to have to write a plugin, which at least means you'll follow coding standards, have test coverage, and all the rest of it, rather than just sticking random unreviewed crap into your build like happens in every other build system.
> Maven is a nightmare to use, it's so complicated I would generally not use it. I would just like a package manager which is only doing packages like any other language.
Before Maven, generally I remember there being Ant. And I remember that if an application needed dependencies, unless one explicitly used a dependency manager like ivy, one had to go find the jars and download them, and ensure they were on the class path. Ant was simpler, in the sense that if you wanted something to happen, you would create an ant target and instruct ant on what was going to happen.
Maven isn't simple in the same way, so it does require one to learn more about how it works in order for things to fit together, but I find it drastically simplifies working with java projects. The location of all dependencies are defined, they are downloaded, and there is default behaviour to be expected with each of the maven goals. Overridable properties enable one to have a build which works first time directly after checkout. I much prefer it to what was there before.
If we look at what has come since - sbt, gradle, and leiningen all seem to use a similar mechanism to Maven for dependencies.
sbt, gradle, and leiningen each bring a better syntax to build scripts, viz their respective programming languages. They each pitch the ability to drop out of their declarative syntax when needed, but from the samples I've seen of gradle and leiningen use in open source projects this facility is rarely used. I guess it's because replacing procedural build code with declarative was the reason projects bought into Ant and Maven in the first place. In my opinion Gradle would do well to replace its Groovy DSL with its own lightweight one with a similar DSL and let developers use Java lambdas to do any procedural customization if it's ever required, just like they removed virtually every line of Groovy from their codebase for Gradle 2.0.
> Maven is a nightmare to use, it's so complicated I would generally not use it.
The maven ecosystem is really nice compared to that of many other languages (e.g. python, javascript.) It's deep in terms of functionality, but for getting started (dependencies) it's not that complex. And a good IDE will take care of all of the boilerplate for you.
> Nothing works by default, you always have to include stuff here and there, write one or two xml files before anything would work,
I do share your dislike of enterprise Java development on the other hand. I worked a JBoss/Spring/Hibernate/Tomcat contract a while back; that thing was an unholy mess which took 4 minutes(!) to start up. However, there are much lighterweight frameworks out there; I'm currently building an app on angular -> dropwizard/guice/jdbi, which overall is quite elegant. No XML in sight (aside from the maven configs).
I also tried some JEE in ~2000 and hated it. How could one accept to code in such a bloated ecosystem?
I'll admit I filtered out a lot of candidates becaused they mentioned stuff like "J2EE Engineer" on their resume, which seemed to imply strong incompatibilities with our coding style...
Fortunately not everyone in the Java community is modeled after JEE (or Maven, Spring, etc.).
Right now I work for a large European bank with Java EE and Wicket. I only touch an xml every 2 months or so. I'm not saying it's better than RoR for example in this regard, but Java EE has come a long way since people here used it, and even if it's still not your cup of tea, you should check out Play framework. I've had personal projects in .NET and I can say that there is a lot more boilerplate and spaghetti code there.
Maven archetypes make Maven a lot easier to use, and the standardization of things such as JPA and CDI and the simplification of EJB has gone to lengths to reduce the complexity if JEE.
That being said, this isn't a "Hello, World" app, but more of using "Hello World" to demonstrate how to set up the full JEE system.
That's routing to the right page, transaction and session control, storing the text of the message in a separate class than the one that returns the response, and using a template to return the resulting HTML.
Looking at the section with the actual example code in it, you could do it in about half that, if you wanted a simple version that just returned "Hello World".
If you don't want routing, templating, separation of concerns, etc. then you wouldn't be using a framework like that, of course.
I think its satirical. We all know Java's Hello World is ~10 lines long. I think the point/joke is that Java EE devs don't keep things simple.
Or rather, better put, Java EE devs always want "routing, templating, separation of concerns", because they consider it better, no matter the current problem at hand.
Taking a cheap jab at Java EE just because their "Hello World" introduction article is a bit lengthy is bad form. Judging by the insulting "kids" reference in your title, Java EE has a completely different mindset than you are used to and the target audience doesn't include you.
That doesn't mean the millions of other developers and billions of other platforms running Java are inferior.
At a previous employer, we've migrated a complex J2EE (with EJB 2.0 and such) E-Banking system to use only Jetty and JDBC directly. No one in operations noticed the difference.
But the developers did. Oh they were about 5x as productive afterwards. With no missing features.
Perhaps I'm not included in the target audience. But if E-Banking can do it, what remains of the "target audience" ?
Agreed. It's also possible to use frameworks such as Spring Data/Boot, Roo or Grails to get started really quickly - a bit like the django/rails crowd. Lots of interesting things happening in Java world at the moment.
It seems like originally Java drew from the mega complex enterprise application world influenced by people building large scale C++ apps etc so were hardly aware of the complexity they were adding. Now there is a lot of influence from modern web frameworks to quickly developing and expanding an app.
Touch to maintain some of those old Java apps though from 5-10 years ago in some cases.
The problem with Grails is, like you said, it focuses on getting started quickly, rather then producing a maintainable and performant codebase. I mean, Hibernate is very complex in itself, and adding another layer (GORM) on top of it won't make things better.
If I were to start a new java project, I would probably choose Dropwizard (http://dropwizard.io/), which is more a collection of libraries then a framework.
The business model of the Grails development has always been about integrating various existing software into one branded product for "full-stack" development, such as Groovy and Spring. The Spring and Grails crowds inside Vmware seem to do everything together now (e.g. SpringOne2GX conferences) so I suspect they're now already one group, and that it's the Grails project that's taken over Spring just like they previously took over Groovy.
We have a pretty complex Java EE 7 application but we migrated from JPA to pure JDBC (obviously with abstractions so we can support multiple database implementations, but our current only implementation is PostgreSQL). So it's mainly CDI, JAX-RS (RESTful API), JDBC and timers, and it's pretty great performance-wise and developers are kept fairly productive.
As much as I agree that J2EE is bloated, the fact that you can migrate a project to a less bloated stack and still run it proves nothing. The whole point of the whole "bloatiness" is so that supporting/changing the system in the the long run will be faster, easier, and cheaper.
And yes kids, enterprise applications at large companies are exactly as hard to maintain as you may have guessed (after this article).
Old legacy codebases in Java are one of the worst things I've ever seen. (spiked with old stuff nobody maintains anymore and also nobody pays you to upgrade, such fun times)
Setting up any web stack is a pain in the ass and probably just as long of a tutorial. For example, write out a tutorial which goes from base Ubuntu install to "hello world" on Rails, I bet it's just as long or longer. I suppose it depends on how much detail you want to include. There are just more "one click" install options for other stacks.
(This is untested as I don't have an Ubuntu box at hand – the locations depend on your distro, as with Apache installs.)
There actually are sane people in the Java community – underneath the "Java EE" overcomplexity there are some regular old Java web frameworks that are pretty simple and robust. Unfortunately they can be easily overlooked, as the EE community is loud.
Java is the king of boilerplate, but this PHP snippet (in fact, not even PHP, just HTML) is not equivalent to the tutorial in question. The IntelliJ post covers things like, say, HTML templating or built-in debugger for your web app, which is a bit more than a bash two-liner in the PHP stack as well.
I don't think the point here is to get simple web apps up and running quickly. It is to build large scale systems that are stable. So yes, there will be overhead and lots of boiler plate stuff. Even projects like Django still have this overhead.
At first I thought this was a big wtf but really there isn't much to it. It is a rather good, detailed step by step documentation of how to set up a hello world example. +1
This is not a simple Hello World app, it's a minimally viable end to end EE stack using one particular combination of many available technologies, intended to be deployed within an app server. And I am pretty sure OP knows it if he's deploying apps with "just Jetty and JDBC". Big deal; so what? Why the snarky post?
> 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!
I laughed at the end. Reads like a badly written TV script, with so much buildup, tension and all kinds of weird characters in the beginning and middle of the show, then at the end comes a huge anticlimactic duh. "Hello Word!".
i don't think the point of the article is to introduce JEE , its rather in the very first line :
>>"This tutorial is intended to help you get started with developing applications for Java Platform, Enterprise Edition (Java EE) in IntelliJ IDEA. "
They intend to show all JEE bells and whistles in one tutorial so that , people can look at this and know what they need to do to work on IntelliJ developing JEE application.
Not starting out on JEE itself.Which to be honest might require more of a different learning curve ,
I don't do web apps with java, so I honestly don't know if it's the proper way to do it, a satire, or if there is a more straightforward way.
Especially, I don't see why one has to write both the class HelloWorldServlet and HelloWorldBean; couldn't one just inherit from one class or implement one interface?
You could just have the servlet write "Hello World" directly.
The Bean is not really useful in the example -- it's mean as a stand in, to know how to write one for your business logic needs, e.g user or product bean etc. (Btw, beans are just lightweight classes used mostly as structs, with getters and setters).
>>You could just have the servlet write "Hello World" directly.
It's been years since I've had to write a Java webapp, but from what I remember using the servlet code to directly write the webpage output was considered bad. That was the job of the jsp file. e.g., "views" in bottlepy and Rails: http://guides.rubyonrails.org/layouts_and_rendering.html
Yes, it was considered bad style because of separation of concerns etc, but nothing necessitated JSP, you could just use servlets and any of tons of template libraries.
And for a hello world, a servlet would do just fine.
This page sets up an entire framework / java stack containing JEE, with some exampleclasses for stuff that will be needed later. So it's much more than a simple Hello World. Compare it to setting up any other framework: A lot of files and boilerplate configuration.
Java main feature: fast on JVM, not on the dev.
I've worked for 5 months to make a 4 pages - 3 grid & upload form using GWT, Spring, SOAP.. seriously?? It's a different stack but still it's overkill. You know what is the best part? our app is not even scaled. Why are we bothering then? Do we crunch tons of data to justify the need of a JVM? No. Is speed really a concern? It seems not.. I didn't even hear we are doing caching. It's only transform database beans to DTO and modify for display. Java is not a technical requirement here. It's just a lazy business standardisation solution.
To me It's like, the enterprise wants a flyswatter to kill a fly but you end up with a bazooka factory and the fly dies of age. But the bazooka factory is very efficient on the CPU. That's the important part you know..
And now kids let's build something little more complicated. App with distributed transactions in cluster (each step on different node).
Full JEE stack is terrible if you would like to write sad CRUD applications. But if you need something more than simple access to DB it is very good solution.
I think the usual way would be to use JSF and CDI beans instead of using EJBs and Servlets though. The only thing that is quite annoying is creating the web.xml from scratch for the first time. The shown approach is rather bad for simple (and modern) Hello World.
The main problem with JavaEE is hardly the development part. It's the maintenance and support part. When relatively inexperienced programmers write complex applications (because it makes this easy) and then something goes "wrong" in this pyramid of abstractions and layers and layers of libraries / frameworks interacting with one another and the application servers. That is when it gets interesting. Yeah there are great production performance monitoring tools like Dynatrace but it's not a silver bullet.
Ahh Enterprise. Protip for anyone applying for an enterprise job: just copy-paste https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... when they do the mandatory fizzbuzz test in the job interview. And then complain in the github issue tracker if you didn't get the job.
I'm a complete foreigner to web development and JVM. I've been dabbling in setting up Clojure projects a bit at home. It took a one command line call approximately (lein something-something) to get the more or less equivalent web stack up and running (to my understanding). After reading this, I suddenly understand how awesome that was.
Lackey: "Boss! Boss! Our system is a hopelessly complicated, over-engineered monstrosity! The "Hello World" tutorial is 20 pages! Our business is doomed!"
Boss: "Calm down Jenkins. Just write 'Enterprise' in front of everything, the suits will love it!"
It's way easier to run a Hello World web app with Netbeans!! In fact, a new web app project by default creates a project with default settings/xml with index web page saying "Hello world" - it can't get any simpler than that! give it a try :-)
Nothing works by default, you always have to include stuff here and there, write one or two xml files before anything would work, I'm fine with configuration but I should at least work by default. Maven is a nightmare to use, it's so complicated I would generally not use it. I would just like a package manager which is only doing packages like any other language.
The main problem with the Java community in my own opinion is they are building pyramids while other languages are building stuff out of bricks, it's the opposite of the UNIX philosophy.