Question

I'm almost finished with the book "Head First Java". The reason I'm studying this is I'm hoping to get a job developing with JavaEE someday. Now I'm thinking, should I go ahead and study EE (moving on to Head First Servlets and JSP) or should I spend more time with SE? Would it help? I'll go on and say directly that I want to learn EE in the quickest yet the most optimum time needed (a balanced ind of way). Any advice?

Thanks in advance!

Was it helpful?

Solution

To me its fine to go with JavaEE, as you already did adequate of SE. And certainly hanging out in programming forums will teach you now and then things which are still hidden from you. Believe me there would be many. Anyhow, I am having few advices for you, which will help you down the road.

  • Its better to have a very good command on Java Collection API
  • Another important is to know Java Threading Mechanism and related classes
  • Effective Java is a must read for any Java developer. So go and read it
  • Don't jump into any framework prior practicing plain Servlet and JSP, adequately
  • To know major design patterns is a must

OTHER TIPS

Knowledge is never a bad thing, so more SE is recommended.

But there's nothing wrong with getting your feet wet with EE now. Start with servlets, JSPs, and JDBC. You can do lots of useful things with just these, and it's fair to call it EE.

If you do write JSPs, just make sure that you do it the right way - using JSTL, the JSP Standard Tag Library. No scriptlet code.

A good developer can always easily master APIs. A bad developer can easily misuse APIs. Hence, become a good developer first.

I always dislike the term "moving to J2EE" since J2EE is just a collection of loosely related technologies.

Someone can build build servlets and JSPs but not know anything abougt EJBs, or vice versa. Someone can use Hibernate for persistence or JMS for sending messages without ever considering it J2EE (that is my case, for example).

APIs come and go, but it's most important to become a solid developer in core Java. If you want, read enough tutorials to understand the main concepts, maybe even play around a little in your spare time. Understand important concepts like threading, databases, etc.

For example, understand JDBC before you approach hibernate.

You're ready to go for JavaEE.

When you use it you'll be using JavaSE for JavaEE is JavaSE + new libs.

To me the best ( almost only ) way to learn a new technology is actually working on it. I tried to read and learn about JSP ( back in 2000 ) or any new framework, but I just get bored.

I never get Hibernate or EJB's until I actually got some project in which I could apply it.

I've read a lot of spring and probably I could pass an interview but since I've never used it in a project I don't consider my self that I know it ( Although I know how it works, the config files and even the new changes ).

So my recommendation is, if you can afford it, get a job no matter if the pay is bad, put your hands on any JSP project as soon as you can. The learning will be much better than any Book, Boot camp, Course or anything you can get.

Probably this only works for me. :)

I would agree with the advice given that it's OK to jump into J2EE from learning core Java. That said, I would continuously hone your core Java skills.

When I'm looking for J2EE developers that I want on my team, I look for folks that know how to write simple maintainable code by exploiting the JDK to its fullest extent. You should know the collections API like the back of your hand. You should definitely practice the advice given in Effective Java. Eventually you will have to know some of the subtleties of threading (step 1: keep your objects immutable; step 2: see step 1).

BTW, if you're in the New York area, leave a comment and maybe we can contact each other offline.

Clarification: every interesting Java application will require business logic and the use of plain old Java objects (POJOs). Trivially, that includes J2EE applications, whether it is a web app, a framework for use by web apps, or even a J2EE app server itself. It's usually an eye opening experience for a Java developer once they've developed a "toy" app server. J2EE becomes a lot easier after that.

By my lights, a true J2EE "Jedi master" knows how to take apart an app server to its basic core Java components. E.g. EJBs are proxies that wrap business POJOs by adding the capability for remote procedure calls with the RMI networking protocol as well as a transactional manager. If you understand RPCs, RMI and transactions, your chances of understanding EJBs rapidly goes up.

Or to put it in Joel Spolsky talk, J2EE is a leaky abstraction built on top of the J2SE networking API.

I started working on JavaEE without not enough knowledge of basic Java and I totally regret it!

JavaEE is not just an additional set of APIs, it encompasses so many concepts from EAI, SOA and DBs. Trying to master those concepts, learn the APIs and still getting to know the foundation - Java, was a real challenge.

JavaEE sounds exciting and it is, but if you are someone who wants to produce clean, easy to test and correct code, my advice: start with Java SE.

When we started J2EE none of us had ever coded anything but SE before either; I'd go for it.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top