[HN Gopher] What's New in Jakarta EE 10?
___________________________________________________________________
What's New in Jakarta EE 10?
Author : mooreds
Score : 41 points
Date : 2022-09-14 15:08 UTC (7 hours ago)
(HTM) web link (blog.payara.fish)
(TXT) w3m dump (blog.payara.fish)
| TedDoesntTalk wrote:
| > the new version of Jakarta Concurrency is that it has moved! It
| is now included in Web Profile distributions of Jakarta EE.
|
| Why?
| whartung wrote:
| Jakarta EE has several profiles, each focusing on different
| subsets of the overall EE platform. Web Profile is one of those
| subsets that focuses on the Web aspects of Jakarta EE. For
| example, Tomcat is more of a Web Profile stack (I don't know it
| Tomcat officially supports it or not) compared to the full boat
| EE containers like Glassfish, Websphere, etc.
|
| Jakarta Concurrency (which is essentially portable access to
| container managed thread pools and other similar resources) was
| originally part of the full EE specification. Now they've moved
| it to the Web Profile so it can be used in those containers
| that do not support the entirety of Jakarta EE.
| hsbauauvhabzb wrote:
| Every time I look at the Java ecosystem I feel lost. Versioning,
| package management, naming and 'EE' all seem to be 'in the know'
| things that keep outsiders outside.
| nerdponx wrote:
| I feel this way too. Clojure looks awesome. Kotlin looks nice.
| People tell me that even Java is pretty good now. There are a
| lot of JVM libraries and people say that the JVM itself is an
| engineering marvel.
|
| But... the ecosystem is incredibly intimidating and there is no
| obvious starting point for a beginner. I know that with Clojure
| you can probably just stick to "Clojure stuff" like deps.edn,
| but that's also not really why people choose Clojure in the
| first place, nor does it seem like a sensible path to
| competency.
|
| And I say this as a Python professional and a Common Lisp and
| Scheme hobbyist. My personal tolerance for chaotic and/or
| offbeat tooling ecosystems is high.
| kjeetgill wrote:
| Hmmm, I guess I find it straight forward enough. How can I
| help?
|
| They've simplified it a ton lately. There's no real JRE vs
| JDK seperation any more. The Java Language / JVM versions are
| the same. Version 19 is just out and they release a version
| every 6 months now.
|
| Any other languages like Clojure or Kotlin will have their
| own language versions and might specify a range of Java
| versions they work with.
|
| You can think of Jakarta EE as just a version of some library
| that won't be relevant to you unless you use it. Like
| versions of react or angular or something.
| ktosobcy wrote:
| So.. which ecosystem do you like to look at and feel pleased?
| virtually all of them have some sort of notion of packages and
| versioning
| kaba0 wrote:
| I don't think it is harder than any other ecosystem of similar
| size, it's just unknown to you and feel different.
|
| Jakarta EE is the old Java EE's continuation, which is a huge
| standard for solving many kinds of complex business
| requirements (dependency injection mostly, with aspect-oriented
| programming). In a way it is a Spring alternative, but the
| truth is that Spring also uses several annotation of the
| standard so it more like building on top a subset of it. While
| it is a difficult topic, it is an ecosystem in its own right,
| so I don't think it is meaningful to discuss it with Java
| itself -- one can make a whole career as a java dev without
| touching it.
|
| Package management is basically either maven or gradle, but
| both use the same registry for the most part, so on the surface
| level they both are quite easy to use.
|
| I would guess you mean java's versioning (eg. 8, 17, etc) -
| this couldn't be easier, it's just an integer that increases
| every 6 months. That is, for OpenJDK. This is _the_ JVM-
| implementation, being both the reference and the most often
| used one. It has several forks that you might have heard of,
| but they share more than they differ. Some of these forks
| /vendors provide LTS-releases and this usually targets 8, 11,
| 17, 11+6k versions. That's pretty much it.
|
| In the meanwhile you literally have to use a tool to generate a
| base repo to write anything more complex than hello world in
| the JS ecosystem :D
| doctor_eval wrote:
| Well, I know what all that stuff means, and I'm so very, very
| happy not to be part of that ecosystem any more.
| rawoke083600 wrote:
| Sure this post is probably not for me, but as to feedback, i will
| start that page with a paragraph or sentence or two of what
| Jakarta is ??
|
| Something something java ?
| bee_rider wrote:
| I disagree. A "what's new in <X>" post shouldn't describe what
| <X> is. Most of the people interested in updates on <X> will
| already know what it is, so adding that information to every
| article would be redundant.
|
| They helpfully link to the jakarta.ee site which has an about
| page.
| throw_m239339 wrote:
| Java EE is basically a collection of API that are shared
| accross different Java web servers. It's a spec so basically
| you develop your java app on say glassfish server and you can
| deploy it on websphere, the servers holds all the libraries you
| need to run your app, so you can just deploy some small java
| zip file.
|
| Because of trademark issues with Oracle around the name Java,
| the open source community had to rename all its API jakarta
| instead of java which is completely stupid and is a
| demonstration that Oracle is just here to milk the name Java.
| pantulis wrote:
| Would it be more correct to say "Java application servers"
| instead of "Java web servers"?
| [deleted]
| exabrial wrote:
| Jakarta EE is all of the Java EE spec that are now open
| sourced. Right now in Java-land, the big development ecosystems
| are Quarkus, Spring Framework, and Jakarata EE. Jakarta EE's
| big advantage is CDI, which is a very nice dependency injection
| container and allows applications to be broken down and
| composed into easily testable modules. Quarkus partially
| implements CDI and has its own set of APIs. Spring has their
| own DI container that is showing it's age, but is still quite
| popular.
| zokier wrote:
| Quarkus is "just" a Microprofile implementation. And
| Microprofile is largely evolution of JavaEE. Spring might
| have been a breath of fresh air in the JavaEE 6-7 days but I
| feel it has been since been leapfrogged by JavaEE/MP
| gavinray wrote:
| Quarkus is Jakarta EE compatible (MicroProfile), for the
| subset of Java/Jakarta EE that it implements. That's largely
| the appeal.
|
| The most recent release of JEE has a new "Core" profile,
| which is stripped down to bare minimum for AoT-compilation
| and small memory footprint and implements CDI 4.0 Lite (based
| on Quarkus' "ARC" implementation)
|
| https://jakarta.ee/specifications/coreprofile/10/
| whartung wrote:
| Oracle open sourced and released the bulk of the Java
| Enterprise Edition specifications and source code.
|
| But what they did not do, is release the Java trademark. So,
| the whole kit had to be called something else (in this case
| they chose Jakarta, which has history in the Java community and
| lets the colloquial "JEE" still work).
|
| Part of this process what they had to rename ALL of the Java EE
| packages from the original "javax" root name to something else,
| again, in this case, "jakarta".
|
| This has been a several year process that's held up a lot of
| advancement in the platform as it transitioned out of Oracle
| and over the Eclipse foundation.
|
| At this point with moving to Java 11 and supporting Java 17 (no
| small feat), and having all of the packages renamed,
| repackaged, re-released, Jakarata EE is probably "finally free"
| from where it was back in "Java EE 8".
| latchkey wrote:
| As the co-founder of Apache Jakarta and first hearing about this
| Jakarta EE thing just now, which also seems Java (tm) related, it
| seems like a weird overlap in naming.
| [deleted]
| pcdavid wrote:
| Relevant: https://jakarta.ee/about/faq/#collapse-1
| throw_m239339 wrote:
| Are you the co-creator of Jakarta Tomcat?
| latchkey wrote:
| No. Tomcat was created by James Davidson, who worked for Sun,
| and then heavily modified once it was over in Apache Jakarta.
|
| I did a few contributions to the codebase (I wrote the first
| class reloader implementation), but was super busy with many
| other codebases at that point that I had started/created...
| Turbine, Velocity, Multiple Commons projects, etc.
| mdaniel wrote:
| According to Wikipedia, it happened in 2018 and was (of course)
| due to Oracle's trademark on Java™:
| https://en.wikipedia.org/wiki/Jakarta_EE#cite_note-7
|
| relevant: https://xkcd.com/1053/
| latchkey wrote:
| Oh interesting, thanks for this!
|
| It is no wonder that they couldn't come up with a better name
| [0]. For anyone else wondering, we came up with that name
| because it was the name of the conference room that we met in
| at the Sun campus to discuss creating Apache Jakarta, because
| Sun was upset we were originally using Apache Java. As a
| 'gift' of appreciation for making a halfway decent servlet
| engine at the time (Apache JServ), they also gave us Apache
| Ant and... Tomcat. The rest is history...
|
| I've also been long out of the Java ecosystem, so that xkcd
| is especially relevant. Let's go shopping!
|
| [0]
| https://twitter.com/codinghorror/status/506010907021828096
| (this keeps coming up for me recently for some reason)
| kaba0 wrote:
| Well, let's add that the project didn't want to continue with
| the "standard committee"-like model, so they quit on their
| own accord, not due to some malicious intent on Oracle's
| part. But as a now outside entity it would indeed wouldn't
| make sense to use the standard lib's packages, so a change
| was necessary.
| bitwize wrote:
| Jakarta EE is Java EE. When Oracle bought Java they cut Java EE
| loose because Spring and Spring Boot were eating the world and
| Oracle didn't want to be in the business of maintaining the
| losing Java enterprise framework. But they couldn't call it
| Java EE anymore because Oracle holds the Java trademark.
| exabrial wrote:
| One aspect I don't want to see go away is "configuration goes in
| the app container"... basically, if you have a datasource, define
| it at the app container level, then the application just requests
| it by name, not caring what it's actually connecting to.
|
| Happy to see acceleration of these API definitions. One thing I
| miss is having a "big picture" plan for all of EE APIs. It'd be
| really nice to have _Everything_ be defined as a CDI portable
| extension for instance.
| ysleepy wrote:
| I'm the opposite, can't wait for app containers to go away.
| Probably have their place but it's giving up control to some
| stateful black box. I always embed a jetty or something and do
| my own hikaricp.
| pjmlp wrote:
| They are so cool that now there are startups reinventing them
| with WebAssembly.
___________________________________________________________________
(page generated 2022-09-14 23:01 UTC)