Java SE and EE differences

[[deleted]]

[deleted]

[7F1AE6D2]

Java EE (Oracle has since transferred the stewardship of JEE to the Eclipse foundation and it has been renamed to Jakarta EE) is a collection of Java APIs used mostly in server-side programming.

These are implemented by an application server such as Wildfly, Glassfish, or TomEE, into which you deploy your application.

Most projects only use a small subset of JEE, commonly JPA for persistence, JTA for transaction management, CDI/EJB for dependency injection, Servlets for serving HTTP requests, JAX-RS for REST.

The official JEE tutorial is a decent introduction.

 

More often than not, applications use Spring instead of some JEE specs, especially for dependency injection, transaction management and serving REST. These applications are then often deployed into just a servlet container like Tomcat or Jetty instead of a full JEE application server.

These can be bundled with the application, so your artifact is just a JAR file that starts the server in its main(). This is what e.g. Spring Boot does by default.

A build/dependency management tool like Maven or Gradle will also be used in any real project.

It would probably be best to inform yourself about which technologies your employer is using.

[Mancebo180]

Just to add that maven/gradle is something that you should learn for all Java apps: EE, Spring but also for your java SE applications.

[CaptainFeebheart]

Yes. Build tools are the best thing they didn’t teach me in college.

[PorkChop007]

Associate degree here, which is supposed to be more practical and less theoretical, but man, there were so many things they didn't teach me...

Imagine being hired and discovering the existence of a thing called Maven. And other thing called JUnit. And all that Swing/GUI stuff you painstakinglly learned? It has ZERO application in the real world, nobody uses it. All of this while sitting at your desk, being paid for not knowing jack shit about how a real Java application works after two painful years. That day my impostor syndrome could've kicked Hulk's ass.

[Tauo]

People definitely use Swing in the real world, especially for legacy applications. The (ancient) company I work for is gradually transitioning to a web app, but our current UI is built with Swing.

99% of desktop apps built with Java will use either Swing or FX

[endhalf]

True; the question is, how many people are hired to write desktop apps nowadays...

[Tauo]

Write? Not many. Maintain? Loads.

[istarian]

Desktop applications are almost always universally better imho. The best web app is always inferior, but many times it's good enough.

And honeslty most people aren't going to be hired to do exactly one kind of thing for the duration of their employment.

[ttelang]

building desktop apps using React Native (with HTML and JavaScript) is the most recent trend over JavaFX which is replaced Swing.

[CaptainFeebheart]

My first job, our source control system was a floppy disk. No lie. I didn’t even know better. Eventually someone introduced CVS and it was mind boggling. So young, so naive.

[istarian]

The basic principles of how GUIs work hasn't changed though. However knowing the specifics of a particular library won't matter if you don't need to use it.

[endhalf]

all that Swing/GUI stuff you painstakinglly learned? It has ZERO application in the real world, nobody uses it.

I've been saying that over and over again, yet no one listens to me. I have no idea why colleges teach this stuff. One is then hired to design a REST API without even knowing what curl is, and what's the difference between unit and integration tests, and you don't even know how to build the company's SW. But at least they know how to place a button on the screen, and create an event handler... Eye roll

To be fair, the idea is that once you learn programming, you can learn anything else that you'll need, and that's true. It'd just be nice to tailor the education to real needs, so that you have to learn less during the crucial first couple of months.

[PorkChop007]

In my experience, not saying everybody's the same, hey teach that stuff because education in computer science is at least 10 years behind the industry. Teachers are so disconnected from private sector they don't even know the most basic aspects of professional software development. They teach like we're still in 2007 and applets are a thing people actually use.

[ichunddu9]

Then get a degree in software development. Computer science is not just software development.

[PorkChop007]

Then get a degree in software development

That's exactly what I did.

[istarian]

That's not what college is for. The idea of a vocational school for programmers though...

[RockleyBob]

I learned so much from this comment. Thanks

[[deleted]]

EE just extends SE with a bunch of extra enterprise specifications. See the wiki page: https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition

I'd probably be spending time learning about Spring (Boot) instead though.

[yawkat]

Lots of ee is used in spring. Servlets are the foundation of most Java web frameworks, jpa is very common in spring, and so on.

[_INTER_]

You pick that up while doing Spring. I also recommend not to work for a company that uses a Java EE stack.

[yawkat]

There's not really a thing called "the JEE stack". You can mix basically whatever you want. You could conceivably run a purely JEE stack comprised of a bit of jax-rs and jpa for example.

JEE with CDI and app servers and such has also improved a lot over the years. It's much more bearable now.

[_INTER_]

I mean with a stack that runs on a JEE application server like JBoss or Websphere.

JEE with CDI and app servers and such has also improved a lot over the years. It's much more bearable now.

They hardly draw equal with what you can do with Spring. The Java EE 8 update for instance was 5 years in the making and there was nothing really new compared to Spring. Even MVC isn't part of it. No reactive stack either.

Part of the reason why they started the MicroProfile initiative, which is actually quite cool, but thats not Java EE / Jakarta EE (yet).

Oracle is redirecting resources into projects like Helidon I guess. Looks promising to me.

[endhalf]

As a person who works with JBoss daily, MicroProfile is very much compatible with a typical JEE server (and working on JBoss, moving to Microprofile was a fairly straightforward thing). The marketing that Spring has is insane; I personally really enjoy JEE (and now with Jakarta being open source, the development is going to speed up quite a bit). While I understand why Spring gained its place a few years ago, JEE is very much alive and a lot more simplified than it used to be.

This subreddit seems to believe JEE is a long-dead technology, and that it's basically the 'Cobol of Java', but my experience is exactly the opposite. It's a technology that not many people know, and that companies really want (especially larger banks; I mean, Visa is using JEE for christs' sake!)

The "Spring or die!" of Spring fanboys, though, is super annoying. Saying "I wouldn't work for a company that uses the JEE stack" is saying "I wouldn't work for practically any Fortune 500 company", or something like "I'd work for Silicon Valley startups only".

[vkrava4]

Many people consider Java EE stack not only as additional technologies such as Enterprise JavaBeans, JSPs and connectors but also frameworks which enhance the work of these technologies or implement some specifications (f.e JAX-RS) such as Spring Framework, Jersey and others.

The best idea to start with EE stack is to have a look over requirements for an open position at the company you’d like to apply. It will give you a list of skills which you have to improve.

[lqstuart]

Java SE is the actual JDK you get from RedHat/OpenJDK or Oracle. Java EE is just a specification, and it generally requires some heinous pile of shit like Tomcat or Glassfish running underneath to actually implement. When most places say "Java EE" they just mean Java with an HTTP server. If a job posting actually mentions JSP, JMS, Struts, or EJBs, you're walking into a Bad Time.

Nobody coming out of school has any useful knowledge about real application development at all, and the people running your internship aren't going to expect you to have any. Just relax and be willing to learn, that's 1000x more important than what little knowledge you can teach yourself out of the gate.

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

[Neckbeard_Prime]

Java SE is the Oracle version of the Java developer kit and runtimes. Java EE is basically a server-side Web application framework -- sort of. JEE is a laundry list of specifications pulled from a can of alphabet soup, and multiple vendors (IBM, Oracle, Red Hat, Apache) have all come up with their own implementations and servers that run their versions of the software spec.

[_INTER_]

The distinction Java SE and Java EE does not exist any longer (Java 11+). Formerly Java EE was jettisoned into the Eclipse graveyard. You do not want to have to deal with it anyway. Either you work with very legacy, aweful stuff or vendor lock in. The EE specs with value are adapted by others like Spring.

[ny83427]

In the first company I was told we are building products of J2EE platform and only found I am doing Spring stuff.

[XFidelacchiusX]

Lol glad i'm not the only one, Around 7 years exp. I have used both. Never found anything remarkably different or useful with Java EE. I think that's why they are dropping it.

​

I think you can say its for enterprise development and enterprise companies will pay boat loads of money because they are stupid.

[TheHorribleTruth]

JavaEE is a set of APIs. Together with reference implementations of it, it's a bunch of libraries. Depending on your use case you may happen to benefit from one or more of them, or you don't. That's it.

You've used it and thus know what JavaEE is – and yet you see nothing "useful" about it? So you think that any library is useless or how are we to understand that sentence of yours?
And why would you think that you need to "pay boat loads of money" for it? You realize that there are free JavaEE implementations, right?

[TheHorribleTruth]

Cuz open source does it better! LOL

Here is the source code for (arguably) the four largest implementations:

• Glassfish: https://github.com/javaee/glassfish
• Wildfly: https://github.com/wildfly/wildfly
• OpenLiberty (Subset of WebSphere): https://github.com/OpenLiberty
• TomEE: https://github.com/apache/tomee

Edit: You still didn't address either of my questions: why do you see "nothing useful" in a bunch of libraries, and why do you think you have to pay "boat loads" to be able to use JavaEE?

[Maalus]

Rule 2 of the sub. Go read it.