Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Java EE Startup: Filtering information with zeef.com

adam-bien.com

Post reply on HN
Print view View original

81–90 of 104 posts

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

#81

Post by needusername »

henk53 wrote: post #74
StevePerkins wrote: post #71

Earlier quoted context omitted.

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

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

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. You see JMS predates Throwable#getCause so JMSException#getCause is undefined and you have to use JMSException#getLinkedException. In addition the only way to wait on a Queue without blocking or polling is to use an MDB but there is no (!) standardized way to associate a RAR with an MDB. On top of that JMS is six APIs in one. There is the part old API that you're only allowed to use in Java EE, there is the part of the old API that you're only allowed to use in Java SE and then there a part of the old API that you're allowed to use in Java SE and Java EE. How do you know which methods fall into which category? Since Java EE 7 it's a comment in the Javadoc, otherwise you have to be familiar with the spec (yes, it is on a per-method basis, not an a per-interface basis). Then there is the new API (JMSContext) which follows the same "pattern" but uses runtime exceptions for certain parts until you're at the point where it uses checked exceptions again.

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

> But Spring doesn't have an open design process, where Java EE has.

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.

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

#82

Post by bni »

From the article:

"So our strategy has been to reduce the number of relations between entities to what is strictly necessary, and occasionally to use JPA DTOs when a subset of data is needed for a rather complex entity. Such DTOs are populated using the constructor selector syntax in JPQL queries and JPA is generally smart enough to generate far more optimal queries then."

I have been using this "pattern" a lot lately, its great. looks something like this:

SELECT NEW mypackage.Pojo( e.id, oe.name ) FROM MyEntity e JOIN e.otherEntity oe WHERE e.someProperty = :parameter1

Its also possible to place these in external files, working around Javas inability to have multi line strings after all these years.

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

#83

Post by henk53 »

needusername wrote: post #81
henk53 wrote: post #74

Earlier quoted context omitted.

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

> 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. 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. You see JMS predates Throwable#getCause so JMSException#getC…

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

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

#84

Post by henk53 »

superchief wrote: post #77
henk53 wrote: 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…

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 ?

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

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

#85

Post by john-waterwood »

jincheker wrote: post #79

Try other frameworks like Play, Spring,before you are confident to speak out the word "productive", try other frameworks from other languages like Rails before you are confident about start up speed

I tried rails once. Startup was fast, but after 3 months we got stuck and things weren't so fast anymore.

Modern Java EE let's you start about as fast as rails, especially when starting from a good Maven archetype. The code is immensely simplified. I got a backend service with JAX-RS and CDI running in literally no time!

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

#86

Post by john-waterwood »

needusername wrote: post #78
hibikir wrote: post #24

Earlier quoted context omitted.

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

Fixes don't take years with Java EE!!!

We're using JBoss and there's an updated version mostly every few weeks, months at most. Absolutely not years, that's totally ridiculous and tells me you've never really used Java EE.

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

#87

Post by edem »

edwinnathaniel wrote: post #64
edem wrote: post #3

I can imagine that they feel themselves productive with EJB but only without the contrast say Ruby, Python or LISP would give.

Choosing Java over Ruby/Python for your web-app really depends on what you want to sacrifice. I counted LISP out because unless you're using Clojure, I know for sure you're not going to be able to beat anything else for web-app development. LISP for web-app probably works in the 90's for PG but we're in 2015 where libraries, frameworks, and tools for these other languages are just far too advanced and more productive…

Clojure is a LISP and from my experience I'm way faster with Clojure than with Java. Plus Clojure can use any java library. And by the way it seems that you have never used any lisp for web development. When you bump into the first problem with the bloatware made of 30.000 files and you have to debug it because there were no answers on stackoverflow...then you will find all out about the dark sides of "advanced frameworks".

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

#88

Post by edem »

speakeron wrote: post #9
edem wrote: post #3

I can imagine that they feel themselves productive with EJB but only without the contrast say Ruby, Python or LISP would give.

You may think that, but productivity is really about a smart person who knows their tools. And, of course, at least they won't have do a rewrite when it becomes apparent that they have to scale big time.

This statement is false. If all else being equal the better tool you use the more productive you become. Take assembly for insance. You can know assembly arbitrarily well (and any assembly tools) you won't be faster with assembly than you are with java.

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

#89

Post by needusername »

john-waterwood wrote: post #86
needusername wrote: post #78

Earlier quoted context omitted.

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

Fixes don't take years with Java EE!!! We're using JBoss and there's an updated version mostly every few weeks, months at most. Absolutely not years, that's totally ridiculous and tells me you've never really used Java EE.

JBoss still doesn't have a supported Java EE 7 server. JBoss releases still much less frequently than Spring. If you want to look at how quickly things are fixed in JBoss have a look at this: https://issues.jboss.org/browse/SECURITY-746

If you need a feature in Java EE you have to wait several years for the next Java EE release and several years more for the next server release that implements this, see JBoss.

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

#90

Post by needusername »

henk53 wrote: post #83
needusername wrote: post #81

Earlier quoted context omitted.

> 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. 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. You see JMS predates Throwable#getCause so JMSException#getC…

>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/ja…

> generics

Please

http://docs.oracle.com/javaee/7/api/javax/jms/ConnectionMeta... http://docs.oracle.com/javaee/7/api/javax/jms/MapMessage.htm...

ever heard of enums?

http://docs.oracle.com/javaee/7/api/javax/jms/DeliveryMode.h... http://docs.oracle.com/javaee/7/api/javax/jms/Session.html#A...

Did you read the the JMS Spec or the Javadoc of JMSException http://docs.oracle.com/javaee/7/api/javax/jms/JMSException.h...? Where does it mentions the relationship between #getLinkedException and #getCause?

> The latest API is perfectly fine indeed and doesn't need wrapping by Spring.

Did you ever actually use JMS in production? If so did you listen on a queue? If so did you use MDBs? 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? If you used a stand alone message broker how did you associate the RAR with the MDB and what did activation specs look like?

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

Are you aware of the politics behind the JCP? Are you aware of the JSRs that were shot down by WebLogic before they were even created?

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

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. It doesn't help that you can't create pull requests for Java EE but you can create pull requests for Spring.

Post reply on HN