Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Time to play the game?
I agree with you. Both are valid deployment models that Java EE should support equally, along with the ground-up modularity that customers have wanted from Java EE for a long time now.

I do suspect though that this is neither the right time nor thread to productively discuss this. These are topics that should be prioritized along with what is next for Java EE.

Let me just say for now that I think being able to fully align with Java SE modularity will be a huge marketing win for Java EE. I tried to do what I could to advocate for this internally while I was still at Oracle. The issue of course is feature priorities, legacy runtimes and the significant investment required to make this happen.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxx>
Date: 11/3/17 11:00 AM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Time to play the game?

There's always a trade-off with either fat JARs or light WARs deployed to an app server. Neither of them is actually more lightweight in all aspects. 

- Fat JAR may contain only what is necessary, there's no easy and straightforward way to build it as most solutions like Spring Boot and WildFly Swarm require a special maven plugin and configuration.
- Light WARs may contain only the business logic, but there's no easy and straightforward way to run them in an app server as most solutions require a special deployment tool or web interface to deploy pps

I think both ways to package and run enterprise applications are valid for certain usecases and should be addressed

 - Building fat JARs can be as simple as using a standard tool or a common maven plugin
 - Running light WARs can be also almost as simple as running a JAR, just run `java -jar appserver.jar -app application.war` or `appserver -app application.war` 

The latter is already supported by Payara Micro and Hollow WildFly Swarm (e.g. `java -jar payara-micro.jar --deploy application.war` or `java -jar wildfly-swarm-hollow.jar application.war`). Traditional app servers like GlassFish also provide command-line tools that can do deploy a WAR application into a running server, e.g. GlassFish with `asadmin deploy application.war`. It could be standardized to simplify running and deploying plain WARs. 

There already were attempts to do this with JSR 77 which is too complicated and with JSR 373 which was planned for Java EE 8 but withdrawn. I also created my own proposal for a standard structure of fat JARs, which also covers running WARs with the help of an external runtime from command line: https://github.com/OndrejM/fat-jar-spec Maybe now is the right time to discuss whether it makes sense to standardize something like that in JavaEE.next.

Ondro


2017-11-03 14:22 GMT+01:00 Xuqian Zhang <zxuqian@xxxxxxxxx>:
I think the fat jars are just an another way to structure the enterprise application as the trending of microservices. Each jar file will just provide a specific service and will deploy to different server. The fat jars actually are more light weight because they only need part of the server runtime. 

Wildly swarm is doing this way. Indeed this structure has drawbacks, such as if you want to change the underlying implementation, you have to change every service project. 

On Fri, Nov 3, 2017 at 7:59 AM Mihai A. <amihaiemil@xxxxxxxxx> wrote:
Hello All,

I wanted to ask you how is JavaEE going to fight back to Spring and project Jigsaw?

Let me explain: 

These days, I noticed an increasing trend of developing Java (web)apps with Spring + Spring Boot, and running them with Docker. A lot of people seem to not understand JavaEE, they cannot use it properly so, naturally, they prefer to have a fat deployable and use Docker just as a simple OS wrap.

Then here comes project Jigsaw which, it seems to me, is an effort made in the complete opposite direction of JavaEE. I read this article that kept showing on my Twitter feed: 


Basically, with Jigsaw, we can create standalone Java apps which do not need a preset runtime anymore. It encourages developers to follow the monoliths path, building even fatter apps. Because hey, nobody wants to take care of setting the JRE. But they will still play Docker just to spin the app. Do you see the irony?

I cannot understand why more and more developers build fat applications and use Docker only as an OS bubble. Why don't they use Docker for what it was meant, for setting an environment, a platform (JavaEE) and keeping their applications lightweight?

These days, the developer, instead of focusing on lightweight, efficient projects, is burdened with having to know everything: the app couples together (tightly!) concepts such as Spring Boot, Jigsaw, Docker. Everyone is still happy, they enjoy it, not thinking that we are throwing away many years of progress.

Any thoughts on this topic? It's a rather grim view, I know, but I am really curious of what the experts believe. 

Best regards,
Mihai Andronache
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community


Back to the top