Live data from Hacker News

Java EE Is Moving to the Eclipse Foundation

adtmag.com

81–90 of 144 posts

Re: Java EE Is Moving to the Eclipse Foundation

#81
post #31
post #27

Earlier quoted context omitted.

It's basically Java SE + a standarized stack of technologies, that are usually used in server applications: Servlet, EJB, CDI, JSP, JSF, JTA, JPA... Java EE is not the only way of doing serverside java apps - most of systems i've developed used tomcat + spring-* stack, which is not a Java EE platform. I think reading this project page may help clarify what Java EE is: http://openejb.apache.org/apache-tomee.html

Spring + tomcat is built on J2EE, or at least it was 5 years ago when I worked on that stuff. The servlets API is part of J2EE.

The whole "Spring is really JEE" retort is even more pedantic than the folks who insist on referring to "Linux" as "GNU/Linux".

These days it's more fair to say that Spring "supports optional integration" with JEE API's. You can run modern Spring web/REST apps without a Servlet container. Spring doesn't care whether your ORM implements the JPA interfaces or not. Etc, etc... it's all slowly phasing out.

Re: Java EE Is Moving to the Eclipse Foundation

#82
post #52

Earlier quoted context omitted.

What part of greenfield projects haven't you understood?! Fads come and go, Java stays strong. Many enterprise favor having mature technologies they can count on. A responsible consultant should never advise customers adopting the cool JavaScript framework of the Month (TM), unless it is for building curriculum and write cool "We migrated to tech XXXX" blog posts.

No reason to be rude. You do realize TFA is about putting J2EE to rest, don't you? I'm well aware of Java's qualities on the backend, but ignoring browser innovation for 10 years (iPhone and the push for responsive) or even 15 years (Ajax) isn't good advice IMHO. For better or worse, the same developer attitude and deployment constraints that made Java developers never look beyond the Java ecosystem is happening with…

No more full stack in Java? How about Play, Vaadin, Spring...

Re: Java EE Is Moving to the Eclipse Foundation

#83
post #52

Earlier quoted context omitted.

What part of greenfield projects haven't you understood?! Fads come and go, Java stays strong. Many enterprise favor having mature technologies they can count on. A responsible consultant should never advise customers adopting the cool JavaScript framework of the Month (TM), unless it is for building curriculum and write cool "We migrated to tech XXXX" blog posts.

No reason to be rude. You do realize TFA is about putting J2EE to rest, don't you? I'm well aware of Java's qualities on the backend, but ignoring browser innovation for 10 years (iPhone and the push for responsive) or even 15 years (Ajax) isn't good advice IMHO. For better or worse, the same developer attitude and deployment constraints that made Java developers never look beyond the Java ecosystem is happening with…

Our Java tools keep giving us a full stack.

Talking about fads, the so modern JavaScript frameworks now have discovered how to optimize user experience on mobile by doing, guess what, server side rendering!

Re: Java EE Is Moving to the Eclipse Foundation

#84
post #63
post #48

Earlier quoted context omitted.

That was a nod to that article actually. No one does that now. Someone does some thinking, writes a strong interface, then builds the code behind it. There's usually only one implementation. The advantage comes at the testing phase when you have strong interfaces to mock. I can count on one hand the amount of things we do with multiple inplementations and that's mainly switching cache and file store implementations o…

Testing using mocks usually (a) over-specifies the code under test (e.g. mandating method call order and call count), and (b) under-tests the integration across the boundary - i.e. there's no guarantee that the mock acts the same way as the concrete implementation. I prefer composition through more general abstractions like iterators, consumers, functors etc. where possible. With more general abstractions, there's bo…

Call order and count assertions are important in non-idempotent calls (message delivery for example) and complex integration tests.

While I respect your opinion, it misses three realities. Firstly you can't generalise most complex systems enough for this to be a viable solution universally. Secondly, skill level just isn't on the market to implement this for every case even if you could specify it. Thirdly, to solve the first two problems it costs more.

Data flow moves all the test responsibilities into integration testing, which is much harder!

It's a careful thing to balance but I'm currently on the side of mocks and control flow based systems. They are cost effective and scale well in practice (I think we're on about 4 million or so lines of code and tens of thousands of class levels now)

Re: Java EE Is Moving to the Eclipse Foundation

#85
post #55
post #53

Earlier quoted context omitted.

We have customers were using Chrome is a security risk, because they cannot control its deployments like on FF, IE and Edge.

Fortunately that excuse is no longer valid as they have GPO templates, MSI packages, the lot: https://support.google.com/chrome/a/answer/7358568

Thanks for the heads up, unfortunately it won't change the IT internal guidelines.

Re: Java EE Is Moving to the Eclipse Foundation

#86
post #85
post #55

Earlier quoted context omitted.

Fortunately that excuse is no longer valid as they have GPO templates, MSI packages, the lot: https://support.google.com/chrome/a/answer/7358568

Thanks for the heads up, unfortunately it won't change the IT internal guidelines.

This is when I tend to find a new company to work for :)

Re: Java EE Is Moving to the Eclipse Foundation

#87
post #45

Earlier quoted context omitted.

Factory factory factories... ;) http://discuss.joelonsoftware.com/default.asp?joel.3.219431....

Bet on a software engineering blog to try to make a point using bad paralels with, uh, murdering women.

I do believe that's actually a personality cult disguised as a software engineering blog

Re: Java EE Is Moving to the Eclipse Foundation

#88

Earlier quoted context omitted.

Just replacing XML with JSON doesn't make anything modern.

No, but replacing "programming-in-configuration-files" (whether those configuration files are XML or JSON or something else) with programming in an actual programming language (see eg Maven -> Gradle) is , IMO.

> Maven -> Gradle

Given that my Maven builds run circles around the Android Gradle ones, and that it is still a session subject at Google IO, I hardly see that as progress.

Re: Java EE Is Moving to the Eclipse Foundation

#89
post #15

This is IBM finally beating Sun over control of enterprise Java - something they've been fighting for for well over a decade (and much closer to two). IBM has been trying to get the Java process away from Sun - and they even backed an IDE to compete with NetBeans. Eclipse... of the Sun (Microsystems). Apparently, Oracle has finally gotten tired of IBM (through Eclipse) saying "we can do it better" and trying to manag…

I would argue that Pivotal has beaten both of them with Spring.

Few years back I wouldn't have doubted but today I am not so sure that adding layers of Java framework for all base technologies is sure shot way to win.

Re: Java EE Is Moving to the Eclipse Foundation

#90

Earlier quoted context omitted.

Just replacing XML with JSON doesn't make anything modern.

No, but replacing "programming-in-configuration-files" (whether those configuration files are XML or JSON or something else) with programming in an actual programming language (see eg Maven -> Gradle) is , IMO.

I've always thought of Gradle as a slow Maven with a slightly disgusting syntax[0].

[0] No offense to Groovy; I'm only hating on Gradle's usage here

Post reply on HN