Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Platform popularity
I think I can chime in here. I've arguably the largest (~30 hours) Java EE course out there. It's been live since 2017 and still quite popular. 
People from major companies have taken the course through Udemy For Business and still do. 
Jakarta EE is a very mature framework that won't necessarily have the same hype as any recent framework. 
That notwithstanding, it doesn't necessarily translate to not being used. People using it just don't talk, or frankly find the need to talk about it because it just works. 

What I believe we should focus on going forward is aligning/merging Eclipse MicroProfile into the platform. 
Because having to constantly explain the raison d'etre of MP within the Jakarta EE context creates more confusion.
Then there is a need for quick start guides and how-tos, preferably with ready to use templates. Some form of scaffolding (current option is a mvn command 😑). 
These templates/scaffolds can cater to the myriad of permutations that Jakarta EE can be used. Like Steve mentioned, it can be used in almost any imaginable way possible.

When you get on the Jakarta.ee website, there's a button there that says download, which leads to the download page of the various implementations. 
To a new user, this raises even more questions. Why is the download leading to application servers? What then is Jakarta EE? How do I use it? What sample code can I look at?
Granted, the https://jakarta.ee/resources/#documentation has some good starts. If I'm a developer exploring the platform, I'd be more than inclined to consume the docs as structured in https://spring.io/guides than the other.
I'm quite aware of the great work individual vendors have put in their respective websites to address the issues raised, but the Jakarta EE website is and I think will be the definitive point of reference for a lot of people.

I believe post Jakarta EE 10 is a good place to start revamping and learning from the proverbial new kids on the block how they present their messages to the audience.
There is a lot of work to be done in the advocacy/documentation sphere of the platform because there are a lot of things we've taken for granted as inside players, but are showstoppers for new users.
And the way forward is to reduce the technical barrier/overhead for people to be able to find their way to navigate the platform on their own, with as little head scratching as possible.












On Tue, 6 Dec 2022 at 10:10, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

 

From my experience, the world of Enterprise software development is way more diverse than is credited for on Conferences, Blogs, Twitter etc. There is a huge diversity of industries, organizations and team sizes that develop Enterprise applications on Java. Therefore there is a need for a diversity of approaches to Enterprise Java development. A mono-culture is not healthy for the industry. Where Spring may be the majority it does not have a monopoly on new development. Many organisations are developing new applications on Jakarta EE. Also, despite the hype, not everybody is building microservices, packaged in containers, deployed to Kubernetes and for many, many applications and teams this is way, way too much complexity to manage operationally.

 

Fundamentally, K8s and containers services are just compute infrastructure, like VMs before them. You can already take a Jakarta EE war file and deploy to this infrastructure in many different ways, including hollow jar, fat jar, clustered app server domain or a kubernetes native runtime like Payara Cloud. The true innovation in Enterprise software development in the last decade has been in automated software defined infrastructure not in application development apis. REST has been around over 20 years and still dominates.

 

The simplicity and strength of Jakarta EE, is in the separation of the application apis you use for development from the underlying runtime and compute infrastructure. Jakarta EE doesn’t force a certain runtime model on you like other approaches. You can take an older application and deploy to K8s, Containers, VMs, Bare Metal, JVM Clusters etc. without having to redevelop and repackage. Jakarta EE enables vendors to innovate and compete on runtimes not on APIs. If one vendor drops out developing APIs others will replace them. You can choose the best runtime that meets your needs and the needs of your business or you can mix and match. Choice and longevity are the keywords.

Finally we should forget about the past it does not matter what happened when, what was updated when, what’s popular now etc. We are where we are and the future is what you make it. With the release of Jakarta EE 10 a new era is starting. Jakarta EE can play to its strengths and develop as a strong contender for building Enterprise applications.

 

 

Steve Millidge 

 

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Vano Beridze
Sent: 06 December 2022 06:50
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Platform popularity

 

Hello,

 

I agree with Tobias on the first two points but regarding the 3rd one I have doubts.

Is it a good idea to fight the whole container movement in the IT community? Whether we like it or not, Kubernetes is taking over.

On the other hand, public cloud managed services are advancing.

Java is still the king on the back-end but there are python, _javascript_/typescript, go, .NET core applications and enterprises love diversity.

The idea of having one application server which is more efficient will work only if there are lots of java applications.

 

For me the good platform is the comfort of having a standard set of APIs which provide most of my needs. How the application is packaged and run is the second priority.

 

Once you have coded the Quarkus application and enjoyed dev mode which includes running automated tests as well, it's really hard to move back to the build/deploy cycle. I can live with adding necessary dependencies in the pom.xml compared to having just a single dependency in Jakarta EE app.

 

On Mon, Dec 5, 2022 at 2:30 PM Tobias Frech <tobias@xxxxxxxxxx> wrote:

Hi!

What worked in the good old J2EE times was having an easy to follow and working (!) example front and center that showed what is possible with the technology.

I think this is the challenge for Java EE nowadays:

- Show, that it still can compete with all the new kids on the block out there concerning the features one really needs.

- Make architects and developers understand that having specifications and multiple implementations has a lot of benefits down the road (avoid lock ins etc.)

- Prove, that a system that shares the available resources is more efficient (higher throughput) than all this "let's spin up a new container for this function" stuff out there (scale up vs. scale out).

 

Regards

Tobias

 

Am 04.12.22 um 19:12 schrieb Ryan Cuprak via jakartaee-platform-dev:

  

 My two cents, I think it has also lost attractiveness due to the cloud. Do you write a JAX-RS web service or use AWS API Gateway? API Gateway handles security too. Developers have had all kinds of shiny new toys to play with the last 10 years. Of course, they come with the ultimate vendor lock-in and a monthly bill that makes a cellphone bill look simple (data transfers, invocations, etc.). 

 

 We need to improve documentation, simplify creating a new project, and market it =) Perhaps the Jakarta EE Starter project should be renamed to “jBoot” or “Cloud Boot” etc.  

 

-Ryan



On Dec 3, 2022, at 12:56 AM, Vano Beridze <vanuatoo@xxxxxxxxx> wrote:

 

We lost attractiveness - Oracle's delayed decision regarding Java EE 8, then donation to Eclipse, then holding on to Java EE trademark and related activities took really long time. Java EE was popular, because big names were behind it and actively pushing the agenda.

 

The developers need to stick to something that's not only works but also evolving fastly, brings them joy and job safety.

 

Jakarta EE 10 is a great achievement but if you compare it to Java EE 8, there are hardly any revolutionary changes. Java EE 8 was released 5 years ago.

 

What we mostly do is to make sure platform changes don't affect existing user base, instead of thinking mostly how to become the popular again.

 

What I propose to do is to have just two profiles:

1. Full profile - which is there to support customers who plan to use legacy applications.

2. Core Profile - which is where the exciting staff happens.

 

We need to do identify specs which does not have future and completely stop investing in them.

 

We need to combine forces with MicroProfile community, identify the set of specs which are critical to our success and bring them to life under one name as soon as possible.

 

We need to start thinking how to create good onboarding environment for developers and stop relying on vendors to do that. Jakarta EE starter is the good place to expand, add more documentation, real use cases.

 

We need to stop thinking that because Spring uses small number of specs, Jakarta EE is standard. Spring will never be Jakarta EE compatible and they could easily remove Jakarta EE reliance in one year if they wanted to.

 

Other popular frameworks also are not Jakarta EE compatible and if we want them to be, there should be drastic changes in how we do things. With the current process and dynamics I'm afraid in 5 years there will be proprietary frameworks and Jakarta EE as the failed attempt to have standard in Enterprise Java.

 

On Fri, Dec 2, 2022, 11:04 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi

 

On Fri, Dec 2, 2022 at 7:22 PM Vano Beridze <vanuatoo@xxxxxxxxx> wrote:

I hardly imagine a situation where Jakarta EE will be chosen over Spring Boot or Quarkus if somebody is going to create a microservice.

 

It might help us a lot if you were able to give some specifics about the reasons why you can't imagine that.

 

Kind regards,

Arjan Tijms

 

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
-- 
Frech IT GmbH / Am Brünnele 7 / 71642 Ludwigsburg
phone : +49-(0)7141-9113037 / HR B 744851 / AG Stuttgart
Geschäftsführer: Tobias Frech
mobile: +49-(0)172-7112352 / email: tobias@xxxxxxxxxx

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top