copy pasta because the server is dead (completely dead) ;)
J2EE 1.4 or officially: "JSR 151: JavaTM 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification" was released at 24 Nov, 2003 and was designed to be used with JDK 1.4, J2EE 1.3 was released at 24 September 2001 and is more than 9 years old now.
In JDK 1.4 there were no annotations available, so you had to configure everything with XML. J2EE 1.4 is more Configuration Over Convention, than the current - more reasonable opposite principle of Configuration by Exception or Convention over Configuration.
If I read or hear "J2EE" I always have to think about xdoclet with about 50 lines of XML, a Home Interface, Remote Interface and an unrelated Bean class just to implement a helloWorld() method. ...with Java EE 6 a helloWorld() takes exactly one line of code - as it should be.
Even JDK 1.5 is End of Service Life and so officially dead for greenfield projects as well. Most of the J2EE 1.4 application servers were not even officially supported on JDK 1.5, so it is truly ancient technology.
However: there is more interests in Java EE 6 - measured in number of session attendees at conferences, blog statistics, number of sold books :-) and project requests, than ever. What also amazed me was the result of my informal surveys after talks at various conferences (JAX, W-JAX, JavaOne and Devoxx). The majority of attendees do use Java EE 5. The minority is using J2EE 1.4. Even the number of Java EE 6 projects seems to be slightly higher, than J2EE. ...and Java EE 6 is only one year young...
So J2EE is dead, but Java EE 6 rocks.
I always have to think about xdoclet with about 50 lines of XML, a Home Interface, Remote Interface and an unrelated Bean class just to implement a helloWorld() method
It amazes me that when people say "J2EE" they're really describing "EJB"
So before anyone thinks he is referring to Java on the enterprise in general; he is not.
Java EE 6 is the current Java enterprise solution.
J2EE is the old, e.g. 1.4 or 1.5. Java EE 6 is far better, and technologies like JPA and JTA are quite powerful. There's also a lot less boilerplate code than before. As another poster said, Java EE 6 rocks for enterprise development, particularly with large teams.
Anyone else noticed this: when you Google for Java related stuff, Google's magic stops working, and you get into a sea of outdated and confusing pages from all kinds of sources.
Also, for most of those results, you'll get some horrible unusable web site, probably with serif fonts to compliment.
No, I never noticed that. It's weird how everyone in the startup community hates on java, when it's probably the most popular language in use today (source: SO tags) - far outstripping trendier languages like ruby, python, erlang, go, or this seemingly insatiable desire to re-write every framework in javascript.
It seems to me that the number of third-party OS libraries and frameworks available in java, both in terms of breadth and state-of-the art, far outstrips the resources available in other languages. It's virtually the default choice for enterprise systems, and a vast array of academic research is also java-based, resulting in a hugely rich eco-system.
I just don't understand why java is not better embraced or more widely adopted amongst the startup community.
Because it's simply more painful to do many things that should be trivial. I have about 8 years of java under my belt and I rarely use it anymore (only a few times in the last 3 years). Instead I use one of those trendier languages... all of which you list are long past the possibility of being only a trend.
There are definitely some great reasons to use java for certain tasks, specifically due to the wide range of library support. If I had to use Java for a greenfield project though I'd probably take a serious look at groovy.
I didn't strike out on my own to write in a language that doesn't make me happy, with thousands of over-engineered libraries that don't do anything I want to do, that's owned by a company that's running around suing people.
After a certain point, there's a base of libraries that is Large Enough. I've never really been wanting with Ruby, at least not in the 'oh, but there's this Java library that does exactly what I want' sense.
Even then, JRuby would make it Just Happen, or maybe even SOA.
There's a hell of a lot of stuff out there written in C as well, that integrate quite nicely with PHP, Python, Ruby and other 'trendy' languages.
Having GD embedded in PHP makes many image processing tasks far easier and less painful than trying to do stuff using Java image libraries (for example).
"It's virtually the default choice for enterprise systems"
then
"I just don't understand why java is not better embraced or more widely adopted amongst the startup community"
"Startups" and "enterprise systems" are, in many (most? all?) cases, worlds apart in terms of needs.
I say this as someone who's done PHP for 14 years and Groovy/Grails for 3.
> "Startups" and "enterprise systems" are, in many (most? all?) cases, worlds apart in terms of needs.
Sorry, I didn't mean to imply that they were; more that the wide adoption by both enterprise and academia has driven the development of a great number of world-class libraries and platforms in java.
I know I have contributed to the java questions on stackoverflow. I have worked in java on and off for 14 years, but the java frameworks, e.g. Axis (of Evil), are often quite over-complicated. The questions are there because of employment and difficulty, not interest and ease.
That said, when I am prototyping, or doing a quick tool, it's usually in Perl. Quicker to write, and runs quicker as well (when single threaded). At least if "quicker" involves I/O, caching in hashes (maps) or sorting/searching. Java is quicker than Perl if you are twiddling ints, or throwing all your data away just after the network gives it to you, though :-)
Ruby is nice too, but I have done quite a bit less of that.
This is more a reflection of the whole Java ecosystem. I am currently maintaining an application that runs - and will continue to run until it's EOL'ed - in Java 1.5. Not that 1.6 is that much better.
Also, there are lots and lots of people who learn just enough Java so they can get jobs in programming. Body shops hire them because they are cheap and because none of their clients, who demand their products to be written with enterprisey brands they read about in enterprisey magazines, will ever look into the code they write. Unfortunately, most of them also learn HTML and build websites.
Yes. You can choose to view only results from the past year which helps but Google really need to fix the problem of previously highly ranked pages becoming obsolete over time.
For a few reasons, I had to take a job maintaining/enhancing some huge government Java applications (largely Oracle based). I thought that there was some interesting things going on in the ecosystem because of what I read about all of the JVM-based hacking. I thought that because all of this hacking there would be a lot of solid, well integrated tools and good documentation.
I had successfully avoided Java for most of my career, so it was also an opportunity to learn something new.
That was a terrible mistake. It's almost impossible to find answers that are relevant. There is very little readable documentation, even directly from Oracle. When you do find a relevant bit of information on a forum or blog, it's either outdated or useless because the author doesn't specify what their environment is.
I asked my colleagues for books, blogs or other resources to help me get up to speed. They pretty much laughed and said I'm out of luck.
I won't complain about the tooling. It's bad, but that may be more a matter of taste than anything else.
I have to respectfully disagree. The docs of just about every java library or framework I've looked at or used have been extensive, detailed and complete.
I wonder how much overlap there is between the packages I've used and the ones you've used. I've only been in the Java world for about 3 months, so my perspective is definitely raw and incomplete. Maybe we just have different criteria for what we consider good documentation.
It's like that for pretty much every language, and really bad for Microsoft technologies. When you are looking for C# advice, apparently Google can only find outdated advice from terrible sites like CodeProject and ExpertsExchange.
I've seen some good results from StackOverflow, but this is pretty spot on. If it doesn't link to either of those two sites or SO, then it may link me to some random programming thread where the problem in question was brought up 4 years ago(or more!) and was bumped 3 times by the author with no or near useless answers.
I agree, Java EE 6 is a huge improvement to older J2EE versions. I am going to spend some time next year helping a friend's company with a Java EE 6 project so I have recently spent a few evening brushing up on for a much improved platform. Not at all what I would consider to be agile but solid infrastructure that saves time on projects that require many components, high level error handling, uniform messaging, etc., etc.
Thank god for that. As a funny related story: a former boss once made me (told me to) give a talk about J2EE, and I had NO idea what I was talking about. I was a PHP developer. My first year employed on the web. I should have refused, but was too unexperienced. If you were there (Scotland 2001), apologies!
J2EE is dead because Spring/Hibernate have replaced them because they are the lightweight transactional enterprise application framework that J2EE never was.
You will need the the EJB 3.0 / 3.1 API in the classpath, or at least the @Stateless annotation.
How to deploy:
Just JAR the class and put the JAR into e.g: [glassfishv3-prelude-b23]\glassfish\domains\domain1\autodeploy
How to use:
e.g.:
import javax.ejb.EJB;
public class MyServlet extends HttpServlet{
@EJB
private SimpleSample sample;
}
And: there is no XML, strange configuration, libraries, additional frameworks or jars needed...
=================
Looks a slight bit more than 1 line to me. Note: the page was linked to from another page indicating you can do 'hello world' in JEE6 in 'one line' of code. Java people have a funny way of counting lines sometimes.
He should have left out that "exactly". The main point is something he highlights at the beginning, J2EE was the triumph of configuration over convention, it had a lot of xml descriptors and interfaces/utility classes to be implemented (this caused by the some architectural decisions that remind me of CORBA).
This stuff was usually auto-generated but you still often had to tweak these file manually.
The polar opposite of modern web frameworks.
J2EE 1.4 or officially: "JSR 151: JavaTM 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification" was released at 24 Nov, 2003 and was designed to be used with JDK 1.4, J2EE 1.3 was released at 24 September 2001 and is more than 9 years old now. In JDK 1.4 there were no annotations available, so you had to configure everything with XML. J2EE 1.4 is more Configuration Over Convention, than the current - more reasonable opposite principle of Configuration by Exception or Convention over Configuration. If I read or hear "J2EE" I always have to think about xdoclet with about 50 lines of XML, a Home Interface, Remote Interface and an unrelated Bean class just to implement a helloWorld() method. ...with Java EE 6 a helloWorld() takes exactly one line of code - as it should be.
Even JDK 1.5 is End of Service Life and so officially dead for greenfield projects as well. Most of the J2EE 1.4 application servers were not even officially supported on JDK 1.5, so it is truly ancient technology. However: there is more interests in Java EE 6 - measured in number of session attendees at conferences, blog statistics, number of sold books :-) and project requests, than ever. What also amazed me was the result of my informal surveys after talks at various conferences (JAX, W-JAX, JavaOne and Devoxx). The majority of attendees do use Java EE 5. The minority is using J2EE 1.4. Even the number of Java EE 6 projects seems to be slightly higher, than J2EE. ...and Java EE 6 is only one year young... So J2EE is dead, but Java EE 6 rocks.