Live data from Hacker News

A Java EE Startup: Filtering information with zeef.com

adam-bien.com

71–80 of 104 posts

Re: A Java EE Startup: Filtering information with zeef.com

#71
post #55

Earlier quoted context omitted.

Oh, I couldn't possibly disagree more. JEE has come a long way, and it's a shame that people unfairly dismiss it today due to their ancient experiences with EJB 2.x. However, JEE is a very conservative stack, which suffers greatly from "design-by-committee". Spring therefore is, was, and always will be at least a generation or two ahead. JEE requires an old-school big honking app server such as WebLogic or JBoss. Lig…

>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 withou…

> 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.

I tried to steer clear of precise numbers, because they tend to change every couple of years... and you can easily date your knowledge by citing them.

However, spin up a new Spring application today (there's an online project generator wizard at http://start.spring.io). Make it a web app, with Hibernate/JPA and the PostgreSQL database driver, and Spring Actuator for automated metrics. Build this generated app. The resulting executable JAR with all dependencies will weigh 24 megs, and that includes its app server.

Ditch the Hibernate/JPA, and use PostgreSQL with Spring JDBC instead (which is often superior to an ORM anyway). Your total deliverable size drops to 13 megs.

Look, it's all Java at the end of the day. Spring plays nice with JEE components, and in practice it's not necessarily such an either/or matter. The Java community has a sliding spectrum of bleeding-edge early adopters (e.g. Scala, Akka, Play)... conservative late-adopters (e.g. JEE)... and pragmatic moderates in between (e.g. Spring). If your comfort zone is on a different spot in the spectrum, or if you disagree with how someone else defines the spectrum, then by all means do your own thing. But the comment to which I replied said that, "There's very little reason to use Spring today". That, frankly, is nonsense.

Re: A Java EE Startup: Filtering information with zeef.com

#72

Perhaps OT: I often swing by Java web/services frameworks every year or so and I never see a good DB migration/evolution story. I'm fairly certain that it's because I don't know where to look or that I'm thinking about it incorrectly, but I've yet to see a Java web/services framework that supports the easy database migration/evolution schemes of Django/South or of Rails. Are these migration schemes not supported for…

I imagine most Java web/services would consider it bad style/coupling to pick just one data back end (e.g. assume everyone uses JPA or Hibernate or what not), which would be needed to support migrations.

Even after Rails, the Java ecosystem is less "everything out of the box" and more "build your own stack". There are some exceptions, e.g. Grails and Play. Although both of those have migration modules:

https://www.playframework.com/modules/migrate-1.3.2/home

https://grails.org/plugin/database-migration

(First hits from Google, so apologies if those aren't the latest/best results.)

And, even then, I think both Grails/Play also try to be backend-agnostic, e.g. the migrations being plugins instead of first-class/backed in, like Rails which assumes "yeah, you'll basically always use a relational db".

Also, re migrations, a shameless plug for my ORM that relies on migrations+the database schema to codegen the rest of the boilerplate: http://joist.ws/.

Re: A Java EE Startup: Filtering information with zeef.com

#73

Modern Java EE has taken a lot of influence from other web frameworks. It is now much more convention over configuration than it used to be. I think it just lacks a new MVC module as an alternative to JSF. If only jersey 2.0's mvc templates were added to the core, I would have considered it instead of other alternatives (e.g. Adding routing to a view from JAX-RS, right now it's not trivial and meant mostly for "servi…

> I think it just lacks a new MVC module as an alternative to JSF. In Java EE 8 such a new MVC framework is indeed coming. From the same startup the article uses as an example: https://mvc.zeef.com/manfred.riem That page is from the MVC 1.0 spec lead (Manfred Riem). It's going to be strongly based on JAX-RS and mimicking how Spring MVC and Jersey MVC now works.

Personally, I think "blessing" UI frameworks as JSRs ("official!") is a bad idea.

I think it leads to the UI framework (e.g. JSF in the past or this new MVC spec) "winning" and getting adopted by teams who, if they had to evaluate several competing non-blessed frameworks, would pick something better/easier/more modern, but instead go with the JSR-backed option.

Although perhaps I'm just being pessimistic. JSRs can probably be a good thing; as a programmer in the JVM ecosystem, I've just never considered "it's a JSR" as a brand of quality/something that should affect my choice, and if anything it's the opposite.

(My pessimism aside, if they're basing the spec on existing good ideas, like JPA did for Hibernate, and JSR-310 did for Joda time, that is at least a smart approach.)

Re: A Java EE Startup: Filtering information with zeef.com

#74
post #55

Earlier quoted context omitted.

>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 withou…

> 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 BI…

>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.

Re: A Java EE Startup: Filtering information with zeef.com

#75
post #53

For rich web applications, GWT is a great option. It is a blessing to write the frontend with the same language and toolchain as the backend, re-using domain classes and constants across the projects. Our current project uses Spring MVC for the backend, exposing REST services, and GWT for the frontend, with Resty for marshalling data structures back and forth. It works really well.

How do you feel about improvements in GWT development speed? In terms of development mode, compilation times and the whole process of making a java code change and seeing the result in a browser? Is there a lot of work on making this better? GWT is nice, but I remember a lot of frustration came from buggy dev modes and compilation times.

We've been using GWT master with both incremental compilation + Java 8 lambdas (!) and it's pretty fun.

Granted, the non-JVM debugging experience is not nearly as magical as it was before, but I believe there is some work afoot to merge SDBG (source map-based debugging in Eclipse) + the GWT plugin. Still WIP.

Re: A Java EE Startup: Filtering information with zeef.com

#76

When HN comment mention how bad is "J2EE", I start to know the it refer to old J2EE (J2EE 1.4 (November 11, 2003)). Now is JEE 7, no more J2EE! Yes, JEE/Java is bad but please, there is no perfect framework/language. Ruby/Python/NodeJS whatever is awesome, but it does not mean that it is perfect langauge either. Now JEE 7 is awesome enough that you should stop mention J2EE . Also, Java maintenance best backward compa…

it's funny to see the same defense over and over. no one said any other framework is perfect, but JEE is design-by-committee crap mainly designed to sell consulting hours. that lack of external perfection does not make JEE usable or worthwhile.

it's funny to see the same defense (JEE is design-by-committee crap ) over and over :)

> that lack of external perfection does not make JEE usable or worthwhile.

So tell me, which framework does not lack of external perfection and make it usable or worthwhile.

Re: A Java EE Startup: Filtering information with zeef.com

#77
post #55

Earlier quoted context omitted.

Oh, I couldn't possibly disagree more. JEE has come a long way, and it's a shame that people unfairly dismiss it today due to their ancient experiences with EJB 2.x. However, JEE is a very conservative stack, which suffers greatly from "design-by-committee". Spring therefore is, was, and always will be at least a generation or two ahead. JEE requires an old-school big honking app server such as WebLogic or JBoss. Lig…

>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 withou…

Sheet, are you really seriuous? I totally disagree with your comments. Spring is always miles ahead of java ee. Java ee copies spring inventions. For me it has been a long road to migrate away from "java ee hell". The less java ee the better and more productive to code. Nobody uses xml nowadays, its called java configuration. And who cares about the final jar/war size ?

Re: A Java EE Startup: Filtering information with zeef.com

#78
post #24

Earlier quoted context omitted.

JSF and EJB are the reason why Java EE is lately considered the "secret weapon". The fact is that both invoke memories of old times where they were very heavyweight and problematic technologies. EJB was a total disaster, where you needed to implement 3 interfaces and inherit from a framework provided base class, compile your code with a special "enhancing" tool and run yet another tool to generate something called st…

The fact that people that have used Java do not realize that EJB3 is pretty good, when it's pretty old! I switched to EJB3 in 2006, and I really couldn't see why people would choose Spring anything instead. The switch to Soap, and then to Rest, was changing a couple of annotations. Not bad for a 9 year old framework. Now, my biggest problem with the stack, and the reason I do not use it anymore, is Java itself. A swi…

> I really couldn't see why people would choose Spring anything instead

Testing. Updates and fixes not tied to server releases (which can take years).

Re: A Java EE Startup: Filtering information with zeef.com

#80

Perhaps OT: I often swing by Java web/services frameworks every year or so and I never see a good DB migration/evolution story. I'm fairly certain that it's because I don't know where to look or that I'm thinking about it incorrectly, but I've yet to see a Java web/services framework that supports the easy database migration/evolution schemes of Django/South or of Rails. Are these migration schemes not supported for…

> I never see a good DB migration/evolution story

There's Flyway and Liquibase. Having that said, once you have branches, triggers, set up subpartitions and have PL/SQL blocks that mix DDL and DML things aren't easy anymore.

Post reply on HN