Developing and running a Java EE Hello World application

http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application

by lukaseder • 12 years ago

119 79 12 years ago

wiki.jetbrains.net

S4M• 12 years ago

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?

coldtea2• 12 years ago

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).

smtddr2• 12 years ago

>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

maaaats• 12 years ago

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.

klez• 12 years ago

Is the point of this saying that J2EE is bloated and that simple operations are made seemingly impossible?

Of course you wouldn't write an "hello world" in j2ee, what would be the point?

All that stuff makes it easier later to write more complex stuff, so I really don't see the point of this submission.

lukaseder5• 12 years ago

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

lmm3• 12 years ago

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.

iSnow• 12 years ago

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.

sgt2• 12 years ago

It hasn't been called J2EE since 2006. That's 8 years.

renke1• 12 years ago

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.

IndianAstronaut• 12 years ago

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.

pearjuice• 12 years ago

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.

lukaseder5• 12 years ago

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" ?

thorin• 12 years ago

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.

raverbashing4• 12 years ago

"But, but.. it's not enterprise!!!111"

How are they going to justify their consultant fees then?

Thank you very much for this comment.

atamanroman• 12 years ago

May be true for J2EE. Java EE plays in a different league.

sgt2• 12 years ago

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.

Kociub• 12 years ago

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.

troels3• 12 years ago

You're right. It's still funny though.

metafex2• 12 years ago

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)

svckr• 12 years ago

Next time, kids, we'll do the same without support from our fancy IDE! O wait, no. Let's _not_ do that.

Terr_• 12 years ago

Apples and oranges. Its not supposed to be a small app, it's a skeleton being built to support something much heavier.

gexla• 12 years ago

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.

smtddr2• 12 years ago

>Setting up any web stack is a pain in the ass and probably just as long of a tutorial.

I beg to differ.

http://bottlepy.org/docs/dev/tutorial.html#quickstart-hello-...

http://howtonode.org/hello-node

(In fairness, I do note that the above examples don't actually have a <button> element to click on before showing helloworld like the Java example)

troels3• 12 years ago

How about:

    apt-get install php5 apache
    echo "<html><body>Hello World</body></html>" > /var/www/index.php

The end.

oblio2• 12 years ago

And are you going to use this process for development work? I doubt that.

Plus, in your example, at the end you're stuck with PHP. I'd rather be stuck with Java EE :)

zeograd• 12 years ago

let's go simpler (and imagine logic coded in vanilla js if this project ever goes bigger :) :

  apt-get install apache
  echo "<html><body>Hello World</body></html>" > /var/www/index.html

bebna• 12 years ago

    apt-get install php5
    echo "<html><body>Hello World</body></html>" > /var/www/index.php
    php -S 127.0.0.1:8080 /var/www/

usef-• 12 years ago

While amusing, I don't think that's a fair comparison as it's not using any framework or persistence features.

A Java app can be written similarly:

    apt-get install tomcat7
    echo "<html><body>Hello World</body></html>" > /var/lib/tomcat7/webapps/ROOT/index.jsp

(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.

twelve40• 12 years ago

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.

makach• 12 years ago

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

AndrewDucker2• 12 years ago

Except that that's not just a "Hello Word" page.

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.

yazaddaruvala• 12 years ago

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.

raverbashing4• 12 years ago

This does almost everything (and sending it to another class is pretty trivial): http://flask.pocoo.org/docs/0.10/quickstart/

AndrewDucker2• 12 years ago

Yup. And by the time you've done all of that, it's not vastly smaller than the code in the original example.

(Also, your setup is spread across every class registering itself, rather than in one central XML file that tells you all of your routing.)

davidgerard• 12 years ago

I used to joke that "hello world" in Java was twenty files and two security holes.

Koziolek• 12 years ago

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.

brianmcc• 12 years ago

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?

kev6168• 12 years ago

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!".

fsloth• 12 years ago

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.

smegel• 12 years ago

Not sure whether to laugh or cry.

estefan• 12 years ago

Ha! What a load of crap! I can't see this "Java" catching on...

realusername• 12 years ago

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.

metafex2• 12 years ago

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.

Sven7• 12 years ago

Also well known as the Enterprise Software Engineer Employment Guarantee Scheme

flavor82• 12 years ago

they were writing an entire persistence framework from scratch (with annotations instead of xml) so they could get away from hibernate.

As opposed to using MyBatis or JDBI? What was their rationale for rolling their own, too many employees on the team?

konradb• 12 years ago

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.

vorg2• 12 years ago

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.

hackerboos• 12 years ago

Maven is awful but the community has adapted and now we have good build tools like gradle.

flavor82• 12 years ago

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).

pacoverdi• 12 years ago

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.).

fddlr• 12 years ago

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.

lmm3• 12 years ago

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.

Delmania• 12 years ago

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.

jupake• 12 years ago

This looks like a deliberately anti-java post or something taken completely out of context.

th3iedkid2• 12 years ago

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 ,

laichzeit0• 12 years ago

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.

tulsidas• 12 years ago

I flew an 747 last week to go to the store round the corner, didn't make sense either

mangecoeur• 12 years ago

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!"

raverbashing4• 12 years ago

Heh it works for IBM

lennartcl• 12 years ago

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.

zero-g• 12 years ago

There definitely should be some IoC container.

jpgvm• 12 years ago

2/3rds of the page before you start writing code. -_- And people wonder why it's going extinct...

ris• 12 years ago

I think as much as anything this shows how using GUIs for complex things can just have the effect of making them exponentially more complex.

assertnotnull• 12 years ago

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..

insin• 12 years ago

Alternatively, here's Adam Bien's (JSON) version of Hello World with JEE:

https://www.youtube.com/watch?v=zESNqWcY0pY

eskimo87• 12 years ago

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 :-)

Developing and running a Java EE Hello World application

Related Stories