It means the whole server-side JDK API, including the servlet spec, jsp libs and JDBC SQL framework under the javax.* packages, whether actually distributed as part of the JDK or not. [0,1,2]

[0] http://docs.oracle.com/javaee/6/api/javax/persistence/packag... / http://docs.oracle.com/javase/7/docs/api/javax/sql/package-s...

[1] https://docs.oracle.com/javaee/6/api/javax/servlet/package-s...

[2] http://www.oracle.com/technetwork/java/javaee/jsp/index.html

> Can someone explain what Java EE really means? I tried to parse the bundle and license the last time this came up, and I didn't really get anywhere.

It's no different than Web standards between browsers, it's a collection of API specifications describing how web applications should be architectured in Java. Then different libraries can follow the spec. JavaEE also has a reference implementation which used to be done by Sun/Oracle.

The problem with JavaEE is, by being too broad and generic, it is incredibly complex and often fails to solve today's developers problems. I mean who cares about JSF(java server face, a way to describe "HTML GUI widgets" in XML) when most applications use a RESTful architecture? Beans session persistance? ... JEE has a lot of technical debt, the word is definitely appropriate here.

> I mean who cares about JSF(java server face, a way to describe "HTML GUI widgets" in XML)

Well, a lot of people did because once upon a time that's how we wrote applications (primarily via server-side rendering).

> when most applications use a RESTful architecture?

Java EE has an API for that...

> JEE has a lot of technical debt

Can't argue with that, but it comes in the form of APIs you don't have to use.

Most enterprise shops do care about JSF.

I know of many greenfield projects using it, mainly PrimeFaces.

They do for legacy apps only, though, since JSP, JSF and everything on top of it, such as portlets and faces component libs, has been obsolete for many years now. Handling UI state on the server just doesn't make any technical sense when there are React, Angular and Co as mainstream GUI kits.

I guess there are still those shops maintaining intranet apps, and for whom it is a priority that everything is 100% Java, or who can't or don't want to invest into JavaScript or another web stack, but I think a responsible consultant should tell these customers that their stack is on life support now.

A lot of enterprise companies aren't buying in JS frameworks because the velocity of those frameworks is too fast. I kind of agree. When you have 50,000 desktops, a 6 month lead dragging a pile of apps over to a new browser is a nightmare scenario. All it takes is one app which the vendor doesn't give a shit about and one internal app deprecating an IE version used by 50 users due to a JS framework change in a branch office and there's a headache from hell on your plate.

Fortunately they're all starting to kick out chrome for business now.

Maybe for those customers it might make sense to donate to the Eclipse foundation to keep JSF etc. alive and to keep Java-only devs afloat? But then maintenance of J2EE has ceased because it's not economically feasible.

It probably would but it won't happen. It's difficult getting anything like that through the layers of purchasing hell.

If they provided a web site with pictures of boxes of software for min $2000 that never arrived and didn't do anything it might work better. The moment someone says "donate" the bean counters start sharpening their pitchforks.

How about labelling that button "support" or "maintenance contract"?

That just gets the legal guys on the case.

We have customers were using Chrome is a security risk, because they cannot control its deployments like on FF, IE and Edge.

Fortunately that excuse is no longer valid as they have GPO templates, MSI packages, the lot: https://support.google.com/chrome/a/answer/7358568

Thanks for the heads up, unfortunately it won't change the IT internal guidelines.

This is when I tend to find a new company to work for :)

Except that these cases are not my employer rather some customers.

In any case, I am pretty much against the mentality here that it is to switch jobs just because something isn't nice and shinny at the current employer, or customer.

Not every place on Earth is like SV avid for software developers.

Most of those companies use AngularJS for that specific reason. It's stable, well tested and documents, and it works.

What part of greenfield projects haven't you understood?!

Fads come and go, Java stays strong.

Many enterprise favor having mature technologies they can count on.

A responsible consultant should never advise customers adopting the cool JavaScript framework of the Month (TM), unless it is for building curriculum and write cool "We migrated to tech XXXX" blog posts.

No reason to be rude.

You do realize TFA is about putting J2EE to rest, don't you? I'm well aware of Java's qualities on the backend, but ignoring browser innovation for 10 years (iPhone and the push for responsive) or even 15 years (Ajax) isn't good advice IMHO.

For better or worse, the same developer attitude and deployment constraints that made Java developers never look beyond the Java ecosystem is happening with Node.js developers, now that Java doesn't give you a full stack anymore (ignoring gwt and echo, which have been deprecated for 5+ years now as well).

Our Java tools keep giving us a full stack.

Talking about fads, the so modern JavaScript frameworks now have discovered how to optimize user experience on mobile by doing, guess what, server side rendering!

No more full stack in Java? How about Play, Vaadin, Spring...

Don't get me wrong, I heard good things about Play, but isn't it Scala? Vaadin I know only from a customer of mine who are using it for server-rendered charting apps and I guess it works well in that capacity. And Spring MVC in 2017? Come on.

My point being that these frameworks are chosen because the options are limited to what's available on the JVM, trading last-gen Java know-how against younger (and sexier) know-how.

It's also a miracle to me why JavaScript isn't more popular with Java developers, of all people, when in fact Java has two mature JavaScript engines, and JavaScript certainly is interesting from a bridge/migration perspective. Years ago Oracle and RedHat had even partial Node.js ports, but it never went very far.

Play is for Scala and Java too. Vaadin does much more than charts--although its wrapping of highcharts is pretty nice--and is quite pleasant if you'd rather write Java than HTML and its close relatives.

I guess from the Java perspective, Javascript does not look too sexy, as it is a small but dangerous / unhelpful language with an uncompetitive-to-Java library ecosystem. TypeScript is great however.

> uncompetitive-to-Java library ecosystem

React, Webpack, CSS compilers and pretty much all other modern frontend (compile-time) asset tools are running on Node.js and install from npmjs.com. Node.js is also perfect for a shallow web-facing container developed along with the front-end as a complement to Java-based (mini/SOA/whatever)-services. So I think it's quite useful to make Node.js workloads run under the JVM.

When we talk about rich libraries we mean actual libraries for generating PDFs, reading barcodes, report generation, talking with all kinds of enterprise databases, GPU programming, parallel distributed algorithms, embedded development...

Not yet another packaging tool or fait-divers like pad left.

And the majority of them written in pure Java, not C++ wrapped in a JavaScript API.

> When we talk about rich libraries we mean actual libraries for generating PDFs

I was specifically talking about web libraries/tools, though. Nobody is saying Java backend development must be abandoned in general.

How do you generate a PDF on such a cool JavaScript front end application?

Hint, you don't. Just hope that the browser does a good job with print to PDF, or run a server side pile of shell scripts, using LaTeX and Postscript, instead of a plain simple library.

And this is just one example from many, where JavaScript/Web sucks on the front-end.

Also Android is front-end development.

A lot of enterprises like to have a solid runtime with proper multi-threading, a comprehensive library set and a stable, well-defined API.

Ask yourself why of all the languages and runtime, it's mostly Java running the enterprise world.

But I haven't questioned Java as a backend technology.

It's basically Java SE + a standarized stack of technologies, that are usually used in server applications: Servlet, EJB, CDI, JSP, JSF, JTA, JPA...

Java EE is not the only way of doing serverside java apps - most of systems i've developed used tomcat + spring-* stack, which is not a Java EE platform.

I think reading this project page may help clarify what Java EE is:

http://openejb.apache.org/apache-tomee.html

Spring + tomcat is built on J2EE, or at least it was 5 years ago when I worked on that stuff. The servlets API is part of J2EE.

The whole "Spring is really JEE" retort is even more pedantic than the folks who insist on referring to "Linux" as "GNU/Linux".

These days it's more fair to say that Spring "supports optional integration" with JEE API's. You can run modern Spring web/REST apps without a Servlet container. Spring doesn't care whether your ORM implements the JPA interfaces or not. Etc, etc... it's all slowly phasing out.

Many of the annotation based APIs from Spring are actually JEE as well.

You can think of it as a standardized API for creation of enterprise web applications.

the more esoteric corners of Java. It's like someone just offered to support windows XP forever. I highly recommenced donating to the Eclipse Foundation, they have made an impact far out of proportion to their size close to Bill Gates, but what they're doing for the good of us all might not be profitable.

There's nothing esoteric about Java EE at all, what are you talking about? It has, among other things, the standard API for creating REST services, data binding via XML and JSON, persistence, etc.