henk53

The matter at hand here was pull requests and the implied notion that those didn't happen in the Java EE universe, which I proved (again) was not true.

Instead of just acknowledging that in whatever way you're just evading the issue (again) and switching to another topic.

But to reply this new topic, TCK has been a thorn in the JCP process indeed. Not every spec has a closed TCK. CDI and Bean Validation have open ones, based on Arquillian, with an open source (OSI) license, and an associated issue tracker where everyone can open issues against it.

Now funny thing here is that CDI is rapidly becoming the underpinning of everything in Java EE. It's the core of Java EE's core.

For some other specs like JSF the TCK is unfortunately closed, but the RI (Mojarra) has such an extensive set of effective TCK tests that I wonder if there's anything at all in the TCK that's not covered by the RI tests.

Still, opening up the TCKs is another battle worth fighting.

>The way you connect the RAR to the MDB is undefined because "expert group" can't be bothered.

And which expert group might that be? Java EE, JCA, JMS, EJB? There's no JCA EG at the moment, just a (former) spec lead who's available for maintenance. There's also no EJB EG at the moment.

As with any open source project, it's a matter of pushing if you really want to get some train getting forward. Linux is no different. Try persuading those guys to accept your patch. No easy feat.

Some things are just controversial in any project. I remember the endless debates in the Pidgin project about the stupid size of the text input.

In Java EE there are debates about having resources inside the war. Many are against, I argued for a long time that they should also be inside, and maybe my emails and posts helped since in Java EE 7 almost every resource can be defined in the war.

But if you first asked it, and asked the wrong person (e.g. this Jesper guy from JBoss) you'll get a NO, GO AWAY! If you are immediately turned down by that, nothing ever changes.

There's this other guy in Java EE who keeps bringing up the topic of standardizing logging, who doesn't seem to get very far. Some things are just not accepted, other things are a matter of talking to the right people, finding like minded souls and keep pushing. Again, no different from any other (big) open source project.

In this case, I'm simply not an expert on JCA, so I can't say if you're right or wrong. You did also say that JMS was not even at Java 1.4, which was clearly wrong, so I do take what you say with a grain of salt if you don't mind (no offense, really).

If this is indeed as badly defined as you claim, please, make your voice heard. Create a JIRA issue, tweet about it (cc @Java_ee or @dblevins). I know David has been fighting to improve JCA and make it simpler.

No product is perfect. If Java EE was utterly perfect than we would not have needed Java EE 8. But guess what, Spring is far from perfect either and by the same token if it was there would not have been a need for Spring 4 last year and there would not have been a need for the next version.

>A very good explanation of what's wrong with JMS.

The article is about JCA and EJB, I don't see JMS itself there.

>I personally spoke to the spec lead at JavaOne and he couldn't be bothered.

Which spec lead are you talking about? Nigel from JMS, or someone else?

>Did you or did you not personally file a single issue?

I love it how you conveniently evade the "prove" I provided that clearly shows that many features that ended up in Java EE originated from community proposed issues. Likewise, if you switch over to the implementation trackers you'll find that patches originate from the community. Be it for Mojarra (JSF), Hibernate (JPA), or whatever.

Whether I personally filed issues is almost irrelevant in the face of the examples I provided to you. But if you really want to know; yes, I filed a ton of issues. In fact, I filed a bunch from the very nick (henk53) I'm using here, as well as many in name of the customers I've been working for.

Quite a lot were resolved. Some in a short time, others took ridiculously long, but were eventually resolved. And some were never resolved. Geronimo is the one and only where I just could not get through to. Funny thing is that in theory they are the most open of all parties.

>Please

Please? You're stating that JMS is not even at Java SE 1.4, then I give you simple prove that it's at Java SE 7, and your response is "please"?

>Did you ever actually use JMS in production?

Yes, rather intensively.

>If so did you use MDBs?

Yes

>If so did you use whatever happened to be the default JMS implementation of the server or did you use a stand alone message broker?

The default implementation, with a JMS bridge. This is a rather powerful setup. The application posts and listens to what are local queues using the default provider. The bridge then transports these to the remote destination.

>how did you associate the RAR with the MDB and what did activation specs look like

Since I didn't use a standalone provider, I didn't go that route. But I DO know that you've changed specs here and are barking against the wrong tree. A RAR is JCA and MDB is EJB, we were talking about JMS here.

While I don't have much experience with JCA, I also do know that things have been simplified a while ago. Take a look at this article: http://robertpanzer.github.io/blog/2014/inboundra-nointfmdbs...

Or read some of David Blevins posts about this topic.

JCA and particular the activation config annotation is rather ugly, I'll agree to that. It's a direct translation of the old XML version and there's room for simplification here. Hey, if you have some ideas why not file a JIRA issue?

>As I said, I take it you never actually tried to do that yourself. I did it for the issues listed above and more and absolutely nothing happened.

Do you have a link to the issues you filed? I'm rather curious now.

When I look at the JIRAs of the Java EE specs I see a lot of issues that were filed by community users and were indeed implemented.

JSF is most well known here. Take a look at: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC

Check what has been implemented in JSF 2 and check that with the issues that were filed. This one makes that rather easy: http://jdevelopment.nl/jsf-22 Now see who filed a lot of those issues. See?

If we look at JMS and I grab this issue, then it's a community member and the issue got included in Java EE: https://java.net/jira/browse/JMS_SPEC-63

Now just grab whatever other spec, say JPA, and look at another feature that was introduced a while back: https://java.net/jira/browse/JPA_SPEC-26

What do you know, AGAIN a community member. You can go on and on. MANY issues that actually ended up in Java EE were proposed by community members.

> It doesn't help that you can't create pull requests for Java EE

Oh? So what is this: https://github.com/spericas/ozark/pulls?q=is%3Apr+is%3Aclose...

And not every implementation is on Github, but many RI implementations take the equivalent of pull requests; patches attached to issues. Boils down to the exact same thing.

Yes, I too would like that every implementation and specifically the RI ones were all on Github, but there are many great other open source projects that aren't on Github either and this doesn't make them any less open source or free. In fact, I just called my old friend RMS (we go way back) and according to him there's nothing in OSI that requires projects to be on Github.

>Spring is always miles ahead of java ee.

So home come Java EE started with no-XML and annotations way before Spring?

>Java ee copies spring inventions.

So why did Spring years later also went the no-XML route and started with annotations?

>Nobody uses xml nowadays,

Because Java EE adopted the move away from XML early. When all major frameworks where moving away from XML, Rod was still trying to let you write MORE XML.

>And who cares about the final jar/war size ?

The Spring guys cared about the size of the combined total when Java EE was still bigger. I can't count the times that Rod ridiculed Java EE about this.

Now Java EE is slimmer and now it suddenly doesn't matter? Funny...

>LOL, JMS. I take it you never actually used JMS. Where should I start? Ah yes, checked exceptions. JMS (of course) doesn't support Java 1.5, the API still uses raw types. Also JMS (of course) doesn't even support Java 1.4.

Strange that several types in the JMS API use annotations (Java 5) http://docs.oracle.com/javaee/7/api/javax/jms/JMSConnectionF...

Or generics (also Java 5): http://docs.oracle.com/javaee/7/api/javax/jms/Message.html#g...

Or AutoCloseable (Java 7): http://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.htm...

Very weird that an API that supposedly doesn't even support Java 1.4 has annotations, generics and AutoCloseable among others (which implies try-with-resources). I didn't know these were all in Java 1.3? :X

>Yes, JMS, perfectly fine as-is and doesn't need wrapping to make it usable.

The latest API is perfectly fine indeed and doesn't need wrapping by Spring. If the Spring guys have suggestions to improve the API even further, why don't they just file an issue on the JMS spec tracker?

>I take it you're not actually a JCP member and tried to get a feature into a JSR? It you were you wouldn't make statements like this. Java EE is open only by name.

You only have to look at the JIRA of the several specs to see how much things that the community suggested went into Java EE. Go ahead, browse through it. You'd be surprised.

>There's very little reason to use Spring today". That, frankly, is nonsense.

We all have our own preferences. I can guess what the "very little reason means". You hear this more often in Java (EE) discussions.

The thing is that in 2003/2004 Spring positioned itself as the necessary layer to make arcane Java EE APIs approachable and usable. With their FooBarTemplates Spring wraps everything that's wrappable, and at the time it made somewhat sense. Rod couldn't wrap EJB though, and as he deemed it "unfixable" he invented his own bean model to replace that.

At some point though Java EE started improving, and then started to improve a lot. Getting first class APIs such as JPA, co-designed by the Hibernate lead himself (Gavin King).

And what did Spring do? As a pavlov reaction they started wrapping again. But the JPA APIs were brand new, perfectly well designed, and didn't need wrapping. This was the basis of the fallout between Hibernate and Spring, and a revealing moment into how Spring operated. They weren't the benevolent dictator who out of the goodness of their hearts wanted to make life better for programmers, no, they just wanted you to depend on their APIs.

Rod later cashed big time, and Springsource, later pivotal became as commercial as the "evil" corporations they tried to wrap with their APIs.

Fast forward to Java EE 7, and Java EE has tons of perfectly fine APIs that don't need the Spring wrapping treatment. JMS, JPA, Bean Validation, CDI, EL, JAX-RS, ... NOTHING of that needs wrapping by Spring to make it usable. It's perfectly fine as-is.

So this is where the often heard "there's little reason to use Spring today" comes from, and I guess that is what was meant. Today Spring is just another platform. Java EE programmers don't need it to make their life better. Programmers in general can choose Java EE, or Spring, or .NET, or whatever.

If your preference is Spring, please, use it and be happy. It's not better than Java EE, but likely not much worse either. I've seen enough Spring code and Java EE code to say it's different, but still fairly equal.

I personally think the design process of Java EE is more open than that of Spring. Both are open source projects, and both have strong commercial influences as well as community influences, but with Java EE the design process is fully out in the open and people can comment on it and contribute. This is less the case with Spring. Yes, the source is open, but so is that of the Java EE RI and many other implementations. But Spring doesn't have an open design process, where Java EE has.

> because J2EE sucks

It does, but Java EE is great! :)

Let's turn it around, what do these "other" ways have as advantage?

It's not sucking less, it's completely not sucking at all. JSF is very powerful and easy these days. I've dabbled in various other technologies, and I think they pretty much all sucked and where much more complicated.

I do like AngularJS 1 somewhat, but it's a client side technology which has its own set of disadvantages (remember why Twitter went back to serverside generation of "ready-to-render-html")

>I don't see much reason to use it, either.

For regular transactions (local, one transactional resource involved) they're still pretty handy as well. EJBs also have things like @Asynchronous, @RolesAllowed and the timer service. The @Stateless concept itself can be just the right abstraction as well.

Eventually though the EJB model will be decomposed and its services made available via CDI.

This is NOT because the EJB model is bad or unworkable, but because it makes sense to align everything on a single component model.

>JEE is design-by-committee crap mainly designed to sell consulting hours.

To whom does Geronimo sell consulting hours?

The design-by-committee hasn't been the case for at least 10 years. J2EE 1.4 was the last version largely developed that way. The last released version (EE 7) and the current one (EE 8) sees a lot of community contributions.

People from the community create JIRA issues, send contributions, even implement entire features (see the work for JSF 2.3 and MVC 1.0).

If that's design-by-committee then everything is design-by-committee.

>Spring therefore is, was, and always will be at least a generation or two ahead.

It should indeed be the idea that Java EE is behind. Its stated purpose is to standardize that what has been proven to work. It doesn't aim to be highly innovative. Instead, it aims to be a stable base on which other technologies can build without having to be afraid that the platform changes underneath them every few months, and without much fear that the platform suddenly changes directions radically.

Keeping that in mind it's funny that CDI is so much more innovative, modern and powerful when compared to Spring Beans. CDI (and by extension Java EE) engaged in the no-XML revolution when Spring was still trying to put MORE code into their proprietary XML format. I've seen Spring applications that were ~50k lines of Java code and ~150k of Spring XML code. Gives a whole other meaning to the term XML hell.

And let's not start about the -contextual- injections and the powerful extension mechanism that CDI pioneered well before Spring was even thinking about such things.

Here Spring is at least 2 generations behind Java EE. And before you start about it, no, CDI was not inspired by Spring. Guice and both JSF native beans and EJB were CDI's inspirations.

>JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use.

JBoss is NOT old-school and big honking (whatever that means). The download size of JBoss is about 110MB, and it starts in about a second. 10 seconds with an app that contains hundreds to thousands of beans.

Compare that to a typical Spring app, where the downloaded size of all things you need easily exceeds 200MB and the war itself is a 100MB or so. A war for Java EE is often some 1 to 2MB for a BIG application. Go figure.

A Spring app with so many beans takes up a minute to boot, at least. Granted, I last checked about 2 years ago, maybe it's better now.

TomEE has been viable to be used for quite some time, and next to TomEE there's also Resin and Liberty web profile which are about as small (some 30MB).

>Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards.

You may get small breakages, but you at least have a chance to migrate!

Imagine migrating your 500k loc application from Spring to Play. Not going to happen. With Java EE I've migrated applications between all major servers. Sure, there were small things breaking, but on average it took me and the team about 2 weeks to fix. 2 weeks is NOTHING compared to a total migration to another platform which can take years.

>With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file.

This is only a fairly recent development for Spring, and Java EE vendors have solutions here as well. TomEE has been capable of doing this for years, and recently there have been solutions for GlassFish (http://www.payara.co.uk/introducing_payara_micro) and JBoss (http://wildfly.org/news/2015/05/05/WildFly-Swarm-Released/)

>Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture.

From the very article this HN post links to, that startup is doing something like that already with Java EE.

>Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size.

Yeah, sure. See my comment above. TomEE is some 35 MB and contains nearly everything you need. Try adding Spring libs and all their dependencies, as well as Hibernate and a transaction manager to your war. That 35MB gets eaten away pretty quickly. And please don't think that just because you only put dependencies in the pom.xml file that the data is not really there. Take a look at the final war that's build. This is often way larger than 35MB when Spring is used.

>I find JEE's CDI to be a clunky mess in contrast

I think it's exactly the other way around...

>Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms

Thymeleaf unfortunately is not very memory efficient compared to JSF's Facelets. See http://www.jsfcentral.com/articles/understanding_jsf_perform...

And Facelets/JSF uses modern templating based on plain HTML these days.

>Microsoft has meanwhile walked away from this as outdated bad practice)

No, Microsoft walked away since they had never been able to put the effort in to create a next gen version of their platform. In JSF terms WebForms is still at JSF 1.1/1.2.

ASP.NET WebForms never had its JSF 2.0 release, and it doesn't have things like PrimeFaces and OmniFaces.

PrimeFaces DID try to make a component set for WebForms, but gave up because the underlying technology was just too outdated.

>If you take a Spring problem to StackOverflow, you will have an answer within minutes.

Uhm, you can't be serious here, are you?

Ever heard of BalusC?

The JSF community is HUGE on stackoverflow, things are answered pretty quickly and there are about twice as many questions (and answers!) there compared to Spring MVC.

>By comparison, the JEE "community" is practically non-existent...

On the contrary, it's really big. Every sub spec has a public JIRA where anyone can submit ideas and looking at the last release indeed many ideas have been implemented that were proposed by the community.

I think you have 2003/2004 in mind and never looked back. Things have changed drastically since then.

>They used two frameworks on top of JSF though.

The interview mentions OmniFaces and PrimeFaces. These are not frameworks on top of JSF.

PrimeFaces is a component library. The entire purpose of JSF was to make such libraries possible. It introduced a component model with exactly the intend that a marketplace of components would appear.

This indeed happened. There's PrimeFaces, RichFaces, IceFaces, Trinidad, and a few others. They don't "fix problems" in JSF, but are what JSF was created to provide.

OmniFaces is a little different. It's a utility library. It does fixes small inconveniences in the JSF API, but it too is not a framework and makes use of the very extension points that JSF explicitly has provided.

Compare this to Eclipse. It's weird to say that JDT is a framework on top of Eclipse, since Eclipse was specifically made to host plug-ins.

>starting stopping J2EE servers is time consuming.

Starting and stopping j2ee servers indeed takes a long time. But so does booting Windows 9 on an old 386.

Why do you bring up J2EE? The article is about Java EE, which is really, really fast in starting/stopping. On my 3 year old desktop (Ubuntu 14.10, 3.4Ghz i7, 16GB RAM, Samsung 830 SSD), JBoss starts in exactly 1 second. Liberty takes 1.5 orso, GlassFish takes between 2 and 3 seconds.

That's not a LONG time, IFF you need to restart.

For typical JSF you don't need to restart at all. You make a change on the page and reload the browser. That's it.

With a standard JVM you can also make changes inside Java code, as long as those changes are inside a method. The IDE will hot deploy only the changed code and the JVM will hot reload it. If you want to structurally modify classes (add/remove methods, add new base class) then you can still hot reload them, but you need to install JRebel. This has little to do with JSF, and more with Java in general.

>you can't see what you screen looks like until you serve the page from your J2EE server

Not true. JSF lets you create pages using normal HTML, which can be previewed from their source.

>Also JSF is an unnecessary abstraction over HTML : it is much easier to maintain state on client itself using any of Javascript libraries like React or Backbone or others.

What's easier is perhaps personal, but I don't think the abstraction is unnecessary. First of all when using normal HTML to create pages there's not much abstraction in the first place, it's normal HTML. Then the advantage is that you can VERY EASILY bind input/output to the server. Client-to-server data binding is JSF's strong point.

And it's not just easy, you also get validation thrown in there for very little cost and JSF is aware of what it has rendered when processing data that's being send back. This allows it to mitigate certain attack vectors, like the mass attribute assignment vulnerability in RoR.

>you will be suprised by the amount of backend code you will have to write.

Funny, how my backing beans are always really small and simple, despite the pages being of arbitrary complexity.

>Ultimately ,you will eventually resort to hacks and you page state and you JSF state for the page will deverge.

Rarely an issue if you half know what you're doing. Client side JSF can make all the changes it wants, and when it's time to update to the server you send that data to the server. Where's the problem?

In every client-server architecture there are sync issues to be aware of. With a js client and JAX-RS the server can also be out of sync if other pages or other clients made changes. This is not unique to JSF.

>I would want to preview my page on different devices' browsers.

What's stopping you?

With JSF you can write normal HTML that you can load on every device. See http://jdevelopment.nl/jsf-22/#1111 and for the older somewhat less capable version: https://en.wikipedia.org/wiki/Facelets

Indeed, technical debt can be there for whatever reason.

It could be that idiot coder who caused a lot of damage in the code before someone finally checked what he did.

It could concern old code created by otherwise sensible programmers at a time when it just wasn't clear how something should work.

It could be a matter of something that was once a good pattern, but by the introduction of something newer has become technical debt (although you mostly would call this just "old code").

And indeed, sometimes you have to hack something in because there's this customer of manager who DEMANDS that something happens NOW.

In general technical debt is basically bad code that when left unfixed will do more damage over time and will often end up costing you more than the times it takes to just fix it.

It's not that far from the truth. C was designed to be very close to the machine and allows mixing in of inline assembly.

This latter feature is almost unthinkable in what most people would call high level languages today (Java, C#, Swift, etc).

For better or worse, Java is increasingly being used in embedded scenarios. Blu-ray players are a prime example, but televisions, settop boxes of various kinds also use Java these days.

>I would love to hear the other side of the story

Me too, it's probably indeed bad, but there's ALWAYS another side to such stories. Unfortunately, we rarely get to hear those.

There have been studies (will update if I find link again) that show that people who care for dogs have lower levels of anxiety. Even "lending" a dog for a few hours per week already had this effect.

Here's another one site that organizes those tools: https://dev-ops-tools.zeef.com

+1

> Java != Java EE

Not every usage of Java involves Java EE, but that doesn't mean Java EE isn't a really valuable tool for many of us. It has had a bad name in the past, but last version have totally changed that and it's now a very sane tech.

Twitter of course is a highly specialized thing that operates on a Scala that almost by definition not every web site out there will be at. It makes sense to build a lot of their own tools and only use lower level infrastructure as a base.

So the JVM and Java is low enough for them to build their stuff on, but many parts of Java EE may be too high level for their very specific use case.

If that pixel then also reflects light like most materials, then yes indeed, it would be the holy grail.

But for the next couple of hundred years or so I think we'll be more than happy with 32k~64k displays or something in that range.

Displays with pixels the size of molecules would effectively be a kind of real-time matter duplicator. Bound to happen one day, but not today ;)

I'd say 8k would be the minimum for that.

Unfortunately on many sites with a supposed tech savvy public "everyone" will start to yell that it's just a conspiracy of vendors and that even 4K is nonsense because your eyes can't possibly see it. They'll show fancy graphs and link to wikipedia articles that supposedly prove that 4k, let alone 8k on desktop screen sizes (roughly 20" to 30") is completely nonsense.

Maybe vendors are picking up some of these sentiments and maybe this is in part holding back progress.

>In the mean time, you have to suffer with text that's not quite as clear as what you get on your laptop or phone

This is really noticeable when you have been working on your desktop screen for some time, then pick up your phone or tablet to read something. You get this instant: "Wow! This is SO much sharper" feeling. Then after reading on that device for 5 minutes you get used to it and don't explicitly experience it as sharp anymore.

But then you go back to working on your desktop screen and you get the opposite experience: "Wow! This IS fuzzy! WTF!?"

The "only eap fixed bugs" are already in the community edition (7.2.Final), but JBoss cleverly called it EAP-alpha/beta this time. So hordes of people don't download it, being scared off by the alpha/beta label.

Contribute and we'll see what it does in round 5 ;)

Java is not that bad at all these days. For years now every iteration of Java EE has become lighter (with respect to the programming model and the startup time of servers).

JBoss EAP 6.0.1 does a cold start in 1.5 seconds on my 2.93Ghz i7. TomEE is some 2 seconds.

If even that's too much, there's JRebel which does full hot reloading of pretty much every piece of code you change.

>it would be interesting how awful they are compared to some of these other languages.

The World Wide Wait benchmark, which tested quite a lot, showed quite favorable numbers for both JSF implementations.

You raise some good points. At one point I've indeed fallen into the trap where I continued improving the mock object until it was a system of its own that was beginning to have bugs that had no relation to any real system the code was to run on.

The mock thus became more of burden than a help, and after reading some posts of this "NoMock" movement, I realized they actually weren't even helping me.

What's in a name, but what name would you suggest? :P