What do you want from JuP?

[Will Hartung]

In another thread:

On Wednesday, July 6, 2016 at 10:51:19 PM UTC-7, Philippe Marschall wrote:

If Micro Profile will require CDI and JAX-RS then it will be a non-starter for us. I don't want to bash CDI or JAX-RS but for us it's simply not interesting. However we do have the need for several other Java EE specs. Modularity would remove to need to come up with a list of specs that we can all agree on are essential for every app.

I wanted to promote this up because I think it's a fair general question.

What are your (not "your" Phillipe, "your" as in everyone, as well as Phillipe) expectations from Java EE Micro Profile (JuP because JμP is to hard for (me at least) to type)?

Why are you here and what would you like to see.

I'm talking in broad strokes, not "oh I want JSR xyz and 123".

What problem are you trying to solve with JuP?

For me, I'm looking for a Fat Jar service solution using technologies that I'm familiar and comfortable with. I'm lazy. I use Java EE because of all the stuff labeled on the tin comes pre-merged and pre-integrated. My server scenarios are such and I don't mind the "baggage" of stuff I rarely use. I like having a problem, being able to dig a bit more in to the spec, and "Hey, look, I have this already!".

I'm not a big fan of vacuuming up every random jar on the internet to solve every small problem I have. I'm in the "I'd rather work with what's in the JDK and Java EE Container", however imperfect, than hunt down a "more perfect" utility that I now have to track and maintain and handhold myself. Simple case in point, java.util.logging is "good enough".

So, I'm looking for utility and low operational impact for my development and deployments.

DropWizard is inspiring, but it doesn't have CDI. I want CDI, and ideally I want transactions. EJB-extra-lite. I can do all this in a thin war today, but I really want a fat jar experience, I want something a bit lighter than a full boat container firing up. Maybe I should just work on a wrapper to make embedding Glassfish easier for my needs and call it a day. But, I'm hoping I can use something like JuP instead.

JAX-RS, and specifically Jersey, is a pretty powerful bit of kit. It's mostly trivial to fire it up from Java SE with a Grizzly engine, and to add Apache Weld to it for CDI. This alone may well be enough for me.

I'm willing for forego Servlets, as JAX-RS is pretty much the "new Servlet". It can do pretty much anything a raw servlet can do. CDI is a really powerful runtime that can be abused in unspeakable ways, giving a lot of flexibility, but most importantly, CDI gives lifecycle. I like objects having a first class lifecycle.

It just seems to me that Jersey and Weld provide simply a really robust stage to build upon, and from it really powerful systems, especially something well suited for a fat jar. Anything else I think I can build up on that platform: MDBs, threads, connection pools, etc.

So, that's what brought me here. Trying to see what others think, seeing if the mating of JAX-RS and CDI can be more formalized, and going from there.

Deploying JuP apps to containers is a non-issue for me, I can take it for leave it. We can already do that with a WAR. If JuP is a WAR runtime sans JSPs and Servlets, then that's ok for me. That's clever. 

I also suggested the idea of Recipes to document how folks can add common things to JuP. "How do I do an MDB with JuP?" Rather than making the runtimes standard, here's a "supported" method of doing it, so that the raw profile is not encumbered with edge cases.

But Phillipe is obviously here for a different reason than me. So, I'm very interested in his, and others, perspective as to why you are here and what you're seeking.

Regards,

Will Hartung

[Werner Keil]

Btw. JuP is quite cryptical. I like and understand puns and word plays, but from "Micro" to "u" it's a bit of a stretch. What's wrong with JmP?

In fact, it also sounds like an short form of "JumP", and Java EE can certainly use some jump-start these days;-)

Werner

[Steve Millidge]

I'm interested in the root of why you want a fat jar runtime? I don't see the benefits of fat jars for containerized JavaEE deployments. Why not layer a well known, versioned, runtime onto your OS Docker image and then just add the skinny war on top of that? This has many benefits wrt to disk space, network IO, time to build the fat jar etc in the CI pipeline. Recently HubSpot posted an interesting blog on this topic http://product.hubspot.com/blog/the-fault-in-our-jars-why-we-stopped-building-fat-jars.

When we decided to create Payara Micro we actually did what you say "work on a wrapper to make embedding Glassfish easier" and we followed the approach of executing your war file in the Payara Micro runtime. While we do support fat jar creation, it is more of a cargo cult feature IMHO.

[David Sharpe]

"Why not layer a well known, versioned, runtime onto your OS Docker image and then just add the skinny war on top of that?"

This is a great approach, but I think the fat jar idea is older than Docker (if not containers) and is easier to understand and implement. The use of Docker for Java EE application servers is relatively new. It's "java -jar mymicroservice.jar" vs. "learn Docker".

To be clear, I think containers are the better technology for Java EE, but I'm offering an explanation for why people are still interested in fat jars. (Personally, I have a lot to learn about Docker.)

That said, I don't agree with "it is more of a cargo cult feature". While containers may be a better solution for developing middleware infrastructure, fat jars still solve some problems, and the Hubspot article you linked acknowledges this, "For years this is how we packaged all of our Java applications and it worked pretty well, but it had some serious drawbacks. [emphasis mine]".

[Will Hartung]

On Thursday, July 7, 2016 at 11:53:12 AM UTC-7, Steve Millidge wrote:

I'm interested in the root of why you want a fat jar runtime? I don't see the benefits of fat jars for containerized JavaEE deployments. Why not layer a well known, versioned, runtime onto your OS Docker image and then just add the skinny war on top of that? This has many benefits wrt to disk space, network IO, time to build the fat jar etc in the CI pipeline. Recently HubSpot posted an interesting blog on this topic http://product.hubspot.com/blog/the-fault-in-our-jars-why-we-stopped-building-fat-jars.

I read that article. I'm not him. I don't have 1000's of these things to manage, so while I get the gist of his point, most of those bullet points don't apply to me. Since "I'm not Google" applies to most of my apps, I can disregard a lot of issues that are more necessary as you scale up to "lots and lots".

When we decided to create Payara Micro we actually did what you say "work on a wrapper to make embedding Glassfish easier" and we followed the approach of executing your war file in the Payara Micro runtime. While we do support fat jar creation, it is more of a cargo cult feature IMHO. 

Sorry, what? I was out clearing some jungle off of my bamboo airplane -- convinced this is why the cans of SPAM stopped falling out of the sky.

Currently, our "monolithic" EAR is 140MB. Gorged with jars from who knows where. Obviously that doesn't include the Glassfish runtime. While we don't have bandwidth issues here at the office, the remote folks do, so since we ship branches of SVN for our code, for those folks we simply build on the remote servers and deploy directly from there.

I can't promise anything, but ideally my future projects with micro services won't be 140MB large. An "empty" Jersey + Weld project is 15MB, which is not outrageous. And appears to have a startup memory footprint of 8-10M. Obviously it's larger than the 10 line "hello world" service that it publishes.

There are several deployment scenarios that can be done that does not require a fat jar, nor a container. The crudest method is a static CLASSPATH. We did that in the early days, and I won't go back. I loathe the CLASSPATH env variable, at least one managed by human hands. But mvn exec will do the job handily. I can upload the skinny jar, the pom, and the config file, and run that. Point maven at an internal repository, and it will suck down any necessary requirements, stand up the CLASSPATH for me, and of and away it goes. Maven even handles the versioning problems. So, unless you want to consider maven a "container", there are ways to work with skinny jars. And this is just stuff off the top of my head.

I don't know why the fellow who wrote that article, with his thousands of services, and billions of file operations didn't write a class loader that can peer in to a bundled lib folder within the fat jar, and just insert the jars wholesale. He didn't even have to write one, he could have adapted the one in Tomcat, since it has to solve this exact problem anyway with jars in unexploded WARs. 

What I get out of a fat jar experience, ideally, is simplicity. I have strategically limited the scope of my container. Jersey is not a trivial runtime, neither is Weld. But it's even less than the entire GF runtime. Ideally my config file will be perhaps a dozen lines rather than 900 like my GF domain.xml. Something I can manage succinctly with vi, rather than asadmin or the GF console. Ideally all of this lowers the overall cognitive load.

Make no mistake, I really like Glassfish and Java EE as manifested by Glassfish. I've been working with it for 10 years, back before it was even Glassfish, and it's filed under my "cold dead hands" folder. I've abused it in unspeakable ways. But I've spent a lot of time single stepping through the container. Sometimes fruitfully, sometimes with futility. GF has a LOT of code. NetBeans gets the shakes when the project is loaded. And, I'm getting to the point where if I can't build it, and grok it, and fix it, I don't want it anymore. I'm a crummy home mechanic. I'll call a plumber to fix a faucet and take my truck the dealer (THE DEALER!) to get an oil change. But I'm pretty handsy with my code.

A tenet I work with, that apparently most folks don't seem to understand, is when you bring in 3rd party code, you may not understand it, but you're responsible for it anyway. I'm responsible for the 1.5M LoC in GF (along with everything else).

So, I'm trying to simplify my applications. JEE offers 100% solutions to all sorts of edge cases that do not apply to me, so I'm happy with an 80% solution that I understand. Writing some quick classes for declarative transactions using CDI does not scare me. Writing a home grown JMS listener that's kinda sorta maybe like an MDB does not scare me.

What the fat jar brings me is less baggage, smaller footprint, lower cognitive load, more control. JAX-RS and CDI, fat and filled with magic that they are, I think will be a perfect foundation to build upon. JAX-RS scratches that "all the BS boiler plate I don't have to do just to get a request marshaled and routed" itch, and CDI gives me lifecycle. I can do anything given a good lifecycle, especially an extensible lifecycle. I'll roll in a Connection Pool, Functional Declarative Transactions, and Functional MDBs.

Make no mistake, it's not a NIH thing driving this, it's simply responsibility for this stuff. Which is why someone else making my fat jar runtime for me is a great idea :). I just want it smaller.

[Antonio Goncalves]

With WildFly Swarm I have the best of both worlds : I can have a thin-war and deploy it "as usual" on an app server, and I can have an executable fat-jar. I would like to still have these 2 options. 

I agree that in a container world, thin war is definitelly more efficient, but "java -jar mymicroservice.jar" is the simplest form of execution, without worrying about too many other technologies (Docker...). If we align on a Fat-Jar structure and allow this "new" form of execution, it would be a good message towards the simplicity of Java EE.

Antonio

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/fdfd2004-f472-4193-8efb-316da582081b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

[Antonio Goncalves]

@Steve, what I see more and more often, is clients being worried about their startup time (more than disk-space or memory). If we can gain a few milliseconds with a smaller JVM thanks to Jigsaw, it would be great to gain a few milliseconds on app server startup, just by shrinking it and taking pieces out.

In some cases (eg. cloud), the fastest, the better.

Antonio

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d6c96eb2-5588-4f7c-8541-ef604799e23b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Steve Millidge]

Hi Will,

I'm not arguing that a smaller, simpler, leaner runtime isn't a good thing. I'm more wondering why a single fat jar is desirable packaging to people.

For some more context to my question. When we first shipped Payara Micro it ran war files using java -jar payara-micro.jar --deploy skinny.war. There's no installation or admin console configuration etc to run your war file.  Having the two jars separate I felt had a lot of advantages as I mentioned above, a known versioned runtime, better for containerization; easy to create wars in IDEs so simple tooling; no arcane assembly step to learn; we can load and deploy wars directly from a maven repo. There was a lot of comments that this wasn't a fat jar solution as we have two jars. So we built the fat jar capability into Payara Micro but I still feel it has less advantages.

Steve

[Werner Keil]

In fact a Spring Boot style "Uber-Jar" makes changes hard as you always have to repackage everything even if just one small piece may have changed;-|

Werner

[David Sharpe]

Steve Millidge: "When we first shipped Payara Micro it ran war files using java -jar payara-micro.jar --deploy skinny.war. ... There was a lot of comments that this wasn't a fat jar solution as we have two jars."

I can't think of any deployment benefit of having one jar over two jars. When I discuss fat jars, I'm referring to running any number of applications from the command line without having to install and configure an application server. Whether it's one jar or two jars is a trivial difference: it's like arguing over 996 jars vs. 997 jars.

[Will Hartung]

On Friday, July 8, 2016 at 1:43:42 AM UTC-7, Steve Millidge wrote:

Hi Will,

I'm not arguing that a smaller, simpler, leaner runtime isn't a good thing. I'm more wondering why a single fat jar is desirable packaging to people.

For some more context to my question. When we first shipped Payara Micro it ran war files using java -jar payara-micro.jar --deploy skinny.war. There's no installation or admin console configuration etc to run your war file.  Having the two jars separate I felt had a lot of advantages as I mentioned above, a known versioned runtime, better for containerization; easy to create wars in IDEs so simple tooling; no arcane assembly step to learn; we can load and deploy wars directly from a maven repo. There was a lot of comments that this wasn't a fat jar solution as we have two jars. So we built the fat jar capability into Payara Micro but I still feel it has less advantages.

I think the desire towards a 1 jar solution is that the program has fewer and fewer environmental dependencies. Arguably this is the pure end goal of containerization in the first place, and an original driver. Not so much in the Java space as in every place else when writing against systems that have large global dependencies. Simply, package managers are not enough any longer in the Linux space to manage dependencies, since they have a global affect. Consider the Ubuntu SNAP packages which act effectively as "uber jars" for applications where, like Mac OS, the applications bring along all of their previously shared dependencies.

We see that also in the optimization of operating system runtimes, where they try to strip them to the bare minimum. "Really, I just need some memory, a cpu, and a socket."

When I push an EAR, that EAR is all inclusive. We don't put libraries within the containers class path. Save for a custom realm and the JDBC driver, which are both container artifacts, not applications artifacts per se, our EARs and WARs are self contained with no global dependencies outside of what the off the shelf container provides, and obviously resources staged within the container (DB pools, etc.)

So, similarly, a single jar is self contained, relying solely on the JDK. It has responsibility for it's own configuration, it's portable with no muss and no fuss. The next step is to bundle the JRE, but not a lot of pressure to do that.

When you say "it's just two jars", well, why if you can do it with two, why not make it just one. I also assume that the WAR in your case is provisioning the container resources (DB Pools, JMS Queues, etc.).

From an operations perspective, a single jar IS "simple". For developers a single jar is simple. Why do I need Docker when I have a standalone jar?

I hang out on the Tomcat IRC channel, and more so than not, the people coming there are random system administrators that somehow got stuck with the responsibility to deploy and/or debug some applications, whether off the shelf, or internal. Giving them a single jar to deploy absolves them of that.

And, finally, for me, embedding the entirety of Glassfish in to a "single jar" doesn't reduce my overall "risk profile" of responsibility that I talked about before.

[Antonio Goncalves]

For me, technically, we already have : 

java -jar any-app-server.jar --deploy skinny.war

A shame it's only implemented in Payara (can't remember if WildFly allows this or not). To be honest, if Java EE 8 wakes up, I would like to see this standardized. 

We have EAR deployment, WAR deployment.... now we need the extra FAT-JAR deployment. And I see that in the MicroProfile.

Antonio

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/22ac8ae5-57bb-40fb-b04c-2b29c066d061%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

Actually Jetty and probably others let you run a single WAR from scratch for a while. Before Paraya existed;-)

Works well e.g. for Jenkins/Hudson, Agorava,...

Werner

[Ondrej Mihályi]

I agree, Werner, that running WAR from scratch, using simple command on command line should be very natural. But it isn't...at least in Java EE world.

I'm strongly in favor to make it very simple to run WAR from command line, using any runtime. WAR packaging provides so many options out of the box over plain JAR, but it does not provide a common way to run it from a command line. I think that is the reason why many people prefer plain JAR packaging and executable JARs these days. In the end of the day, it is very simple to combine a runtime and a WAR file to build an executable JAR embedding the runtime. It was fairly easy to implement --outputUberJar option in Payara Micro: https://github.com/payara/Payara/pull/728/files

--Ondrej

Dňa nedeľa, 10. júla 2016 12:49:58 UTC+2 Werner Keil napísal(-a):

[Sebastian Łaskawiec]

Aside from JSRs and libraries, how about creating a build tool plugin for assembling ready-to-run Docker (?) images?

Of course there are things like this available on the market but having something under the MicroProfile umbrella would be nice in my opinion.

[Will Hartung]

On Monday, July 11, 2016 at 2:10:33 PM UTC-7, Ondrej Mihályi wrote:

I agree, Werner, that running WAR from scratch, using simple command on command line should be very natural. But it isn't...at least in Java EE world.

I'm strongly in favor to make it very simple to run WAR from command line, using any runtime. WAR packaging provides so many options out of the box over plain JAR, but it does not provide a common way to run it from a command line. I think that is the reason why many people prefer plain JAR packaging and executable JARs these days. In the end of the day, it is very simple to combine a runtime and a WAR file to build an executable JAR embedding the runtime. It was fairly easy to implement --outputUberJar option in Payara Micro: https://github.com/payara/Payara/pull/728/files

The only problem with "running a war from the command line" is that it punts on configuring the container based resources that the WAR may rely upon (notably Database Connection Pools, Security). 

Regards,

Will Hartung

 

[Arjan Tijms]

On Wednesday, July 13, 2016 at 7:40:42 PM UTC+2, Will Hartung wrote:

The only problem with "running a war from the command line" is that it punts on configuring the container based resources that the WAR may rely upon (notably Database Connection Pools, Security). 

Although increasingly those resources can be provisioned fairly transparently from within the war using things like @DataSourceDefinition and AuthConfigFactory, and with JSR 375 additionally with e.g. @EmbeddedIdentityStoreDefinition and @BasicAuthenticationMechanismDefinition.

Kind regards,

Arjan Tijms

 

Regards,

Will Hartung

 

[Ondrej Mihályi]

Dňa streda, 13. júla 2016 19:40:42 UTC+2 Will Hartung napísal(-a):

The only problem with "running a war from the command line" is that it punts on configuring the container based resources that the WAR may rely upon (notably Database Connection Pools, Security). 

The container-based resources can still be provided by a separate configuration file(s). I can imaging specifying one or more of the following options to run a WAR file:

When a runtime is embedded in the WAR:

> java -jar application.war --config application.xml

For a standard skinny WAR (microruntime.jar is provided by a MicroProfile provider):

> java -jar microruntime.jar --war application.war --config application.xml

Also, as Arjan said, many things can be defined from within a WAR (e.g. datasrouce) and more are to come in future JSRs.

--Ondrej

 

Regards,

Will Hartung