Developing and running a Java EE Hello World application
wiki.jetbrains.net
wiki.jetbrains.net
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.
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.
As opposed to using MyBatis or JDBI? What was their rationale for rolling their own, too many employees on the team?
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.
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'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.).
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.
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.
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.
(Also, your setup is spread across every class registering itself, rather than in one central XML file that tells you all of your routing.)
And no unreadable and overcomplicated XML for configuration, thank you very much
That doesn't mean the millions of other developers and billions of other platforms running Java are inferior.
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" ?
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.
How are they going to justify their consultant fees then?
Thank you very much for this comment.
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)
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)
apt-get install php5 apache
echo "<html><body>Hello World</body></html>" > /var/www/index.php
Plus, in your example, at the end you're stuck with PHP. I'd rather be stuck with Java EE :)
apt-get install apache
echo "<html><body>Hello World</body></html>" > /var/www/index.html apt-get install php5
echo "<html><body>Hello World</body></html>" > /var/www/index.php
php -S 127.0.0.1:8080 /var/www/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
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.
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.
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
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.
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 has been working fine for many years with no differences between with or without J2EE.
>>"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 ,
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?
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).
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
And for a hello world, a servlet would do just fine.
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..
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.
Boss: "Calm down Jenkins. Just write 'Enterprise' in front of everything, the suits will love it!"