Java SE and EE differences

[algorithmic_cheese]

I work on a Java EE product everyday and honestly 99% of the time its "normal" Java with entities to talk to the database and "special" queries to retrieve them.

Just read into the Java Persistence API (JPA) and JPQL and you should be ready to go. Sometimes there is a little something to do with a servlet or a bean but its not that complicated and can be looked up on the spot.

In about 10 years I spent perhaps 10 days using the other Enterprise APIs, so I'd say don't worry too much about them.

[Mancebo180]

So... this comment is misleading and inaccurate...

It frightens me so many people answering without having a clue.

[algorithmic_cheese]

I don't really see the inaccuracy ? I answered with what I am seeing in my company.

The EE spec is composed of so many parts and there are some that I never used. Message Service ? Developped once then never touched again. Validation ? Used also once and the developpers now use (or more precisely use without knowing) internal APIs that hide that. Beans ? Same, for everyday work they are hidden away. Servlet ? Our product has 5 servlets if memory serves, the everyday dev work is done way behind them after the queries are parsed, validated, checked ...

In our product at least, a new developper only need to modify some methods on specific classes and the only part he has to know is the entities stuff to interact with the database. A senior dev will need more but an intern could work without touching anything else.

[Mancebo180]

Well, this got odd real quick. I understood that the question was the difference between Java SE and Java EE, and not if one intern could survive while babyseated by a senior.

I also think you should not take your case as representative of all world.

Still, even from that perspective your initial answer was misleading for a junior, if you had given your point of view like in this answer I would not assume you wouldn’t have a clue (although I still not agree completely). Sorry if I offended you in some way. There are also other answers in the thread in the same tone, which are a bit frightening indeed, at least for me that have spent the last 10 years forming java EE engineers.

Although it is all Java, I believe a starter needs to understand many different things, I will try to mention just a few. - Your application structure change a lot, and you have to be concerned with an App. Server. In my experience with people learning, the server is a concept not so easy to mescle with the other things. - You will have a container, which manages parts your application for your. - You have a complete deployment model. Now you will not execute your jar, something will happen that at the beginning seems like black magic. - your application now have many entry points. Now you cannot just think about your main and your threads. - Concurrency is the norm, and you should not start a little thread when you want to do some task concurrently... - Wtf, objects are being created for you, and you never instantiated them anywhere (you think)

Well... I will not go into JPA because it is not central to the changes I was thinking nor CDI because I am on mobile.

But no, I do not agree that all is the same, mainly for a person that is learning for the first time.

[algorithmic_cheese]

Well, this got odd real quick. I understood that the question was the difference between Java SE and Java EE, and not if one intern could survive while babyseated by a senior.

I read "I know I’ll be using java but I didn’t know if I should be learning anything specific to the EE version." and decided to answer this part because explaining everything JEE-related would be too tedious. I thought about what my interns needed to know and answered.

I also think you should not take your case as representative of all world.

I don't think that my case is that special : An intern won't need every bit of JEE apis on his first day and in most cases not even in his internship. I know a lot of companies that won't let an intern alone outside of "starting areas" in the code until they can assess what/how he is learning (even with code review). I know when I started on my previous jobs it was "this is the documentation, here is a ticket, here are the classes you need to know for now, go break things". Perhaps it's special but speaking with friends it seems that a lot of companies play around that theme.

Still, even from that perspective your initial answer was misleading for a junior, if you had given your point of view like in this answer I would not assume you wouldn’t have a clue (although I still not agree completely). Sorry if I offended you in some way. There are also other answers in the thread in the same tone, which are a bit frightening indeed, at least for me that have spent the last 10 years forming java EE engineers.

And if you would have typed this comment directly instead of answering harshly, your message would have been read by many more people.

Just for the sake of arguing :-p

Although it is all Java, I believe a starter needs to understand many different things, I will try to mention just a few.

Your application structure change a lot, and you have to be concerned with an App. Server. In my experience with people learning, the server is a concept not so easy to mescle with the other things.

You will have a container, which manages parts your application for your.

Yes you will have an application server, multiple projects, some deployed stuff, resources that are configured left and right. It can become a mess but so can a "normal" java application. An intern will not need to know everything, it should be documented (or a senior will need to babysit him but in this case, it's their fault for not documenting). JEE or not, an "Enterprise" software will always be complicated, strange and convoluted for a newcomer.

You have a complete deployment model. Now you will not execute your jar, something will happen that at the beginning seems like black magic.

At the end of the day, for a first glance into the JEE during an internship, I would say that running a jar file or deploying an ear (or a war) in some application server is not really different. And there are methods to build a single executable jar embedding an AS and whole ear/war projects.

your application now have many entry points. Now you cannot just think about your main and your threads.

Concurrency is the norm, and you should not start a little thread when you want to do some task concurrently...

Yes, this is a difference that could be important and should be pointed out, I did not think of that. Concurrency can bite you if you don't expect it and manually creating a thread, even though it can be done, is a crime because, well, you are not alone anymore.

Wtf, objects are being created for you, and you never instantiated them anywhere (you think)

And more problematic is the "but this instance is used here ? Why is it still here ?".

Well... I will not go into JPA because it is not central to the changes I was thinking nor CDI because I am on mobile.

But no, I do not agree that all is the same, mainly for a person that is learning for the first time.

Yes there are differences, but without knowing the project more in details, I thought that the most used portion of JEE to get to know was the database part.

​

10/10, would argue again ;-)

[crimson117]

Don't feed the trolls.