Re: [jakartaee-platform-dev] Platform popularity

[Vano Beridze <vanuatoo@xxxxxxxxx>]

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