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

Java EE Is Moving to the Eclipse Foundation

adtmag.com

Post reply on HN
Print view View original

61–70 of 144 posts

Re: Java EE Is Moving to the Eclipse Foundation

#61

Post by alangibson »

skocznymroczny wrote: post #57
topspin wrote: post #39

Earlier quoted context omitted.

"JSR (Batch/JSR-352) was particularly disgusting" Good grief. Another mountain of XML programming. It's like the last 10+ years of software engineering never happened. I wonder how many half completed JSR-352 implementations will emerge.

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

Where XML really shines is as an interchange format between the type of mission critical upgraded-once-a-decade systems that are the bread and butter of Big Business IT.

I think XML got it's bad rep from people applying it where it's bulk and complexity is just not needed. For instance, storing configuration for an application that you completely control or shuffling around data inside of an application domain that you can change at will.

Re: Java EE Is Moving to the Eclipse Foundation

#63

Post by barrkel »

cjsuk wrote: post #48
lolive wrote: post #45

Earlier quoted context omitted.

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

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 both less need to mock (there are concrete implementations that are simple enough to use in tests) and the contract is trivial enough to be implemented consistently.

Converting control flow (where modules interact through a rich protocol of method calls) into data flow (where modules interact by consuming data and producing data) promotes both a more functional style, and naturally leads to more testable code with fewer of the downsides of mocks. It also reduces the number of interface-implementation redundantly paired types throughout the system.

Re: Java EE Is Moving to the Eclipse Foundation

#64

Post by LaGrange »

lolive wrote: post #45
cjsuk wrote: post #43

Earlier quoted context omitted.

Where is this sudden DI framework hate coming from? It's just magic object glue that assembles everything based on contract. It's that or factory factory factories or sticky tape. Those are much worse. All the Java EE tech is just a set of contracts really with some canned implementations that magic object glue sticks together.

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.

Re: Java EE Is Moving to the Eclipse Foundation

#65

Post by tannhaeuser »

pjmlp wrote: post #52
tannhaeuser wrote: post #42

Earlier quoted context omitted.

They do for legacy apps only, though, since JSP, JSF and everything on top of it, such as portlets and faces component libs, has been obsolete for many years now. Handling UI state on the server just doesn't make any technical sense when there are React, Angular and Co as mainstream GUI kits. I guess there are still those shops maintaining intranet apps, and for whom it is a priority that everything is 100% Java, or…

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 Node.js developers, now that Java doesn't give you a full stack anymore (ignoring gwt and echo, which have been deprecated for 5+ years now as well).

Re: Java EE Is Moving to the Eclipse Foundation

#66

Post by filomeno »

dfabulich wrote: post #47

My impression is that nobody uses any of the code shipped in Java EE. People use Servlet containers (Tomcat and JBoss) but the problems you can solve with EJB, JSF, JPA, JMS, etc. are all better solved with open source libraries, e.g. Guice, Spring, and Hibernate.

Well, actually Java EE is only a "spec", with no code. There's a reference implementation, though. Sometimes this RI is popular, sometimes it isn't.

Following your example: JPA (the spec) is implemented, among others, by Hibernate. And EclipseLink is the reference implementation for JPA.

Re: Java EE Is Moving to the Eclipse Foundation

#67

Post by pjc50 »

topspin wrote: post #39
needusername wrote: post #33

Earlier quoted context omitted.

Nope, this is Oracle stop caring about Java EE. They are not doing this for Java SE as long as they are caring about Java SE. I also doubt IBM still cares about Java EE. Their last JSR (Batch/JSR-352) was particularly disgusting and seems to be abandoned already.

"JSR (Batch/JSR-352) was particularly disgusting" Good grief. Another mountain of XML programming. It's like the last 10+ years of software engineering never happened. I wonder how many half completed JSR-352 implementations will emerge.

Not even that; this is 1970s batch processing rising again.

Re: Java EE Is Moving to the Eclipse Foundation

#68

Post by EtienneK »

shagie wrote: 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.

Re: Java EE Is Moving to the Eclipse Foundation

#69

Post by mseebach »

skocznymroczny wrote: post #57
topspin wrote: post #39

Earlier quoted context omitted.

"JSR (Batch/JSR-352) was particularly disgusting" Good grief. Another mountain of XML programming. It's like the last 10+ years of software engineering never happened. I wonder how many half completed JSR-352 implementations will emerge.

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.

Re: Java EE Is Moving to the Eclipse Foundation

#70

Post by nly »

smcleod wrote: post #50
rectang wrote: post #22

Earlier quoted context omitted.

Sheesh, there's always someone with this take on foundations. I've heard the exact same phrase many times with "Apache" (where I used to be very active) instead of "Eclipse". :\ Large projects tend to end up under the various foundations because large projects have lots of common problems that the foundations help solve and it doesn't make sense to reinvent the wheel every time (e.g. by starting your own foundation).…

I would tend to agree with those that say the Apache foundation is where projects go to die, to me the Apache foundation feels like a library of legacy often heavy code. OpenOffice (LibreOffice by comparison is doing ‘well’), Wave, Zookeeper, Apache itself etc...

Thrift. Facebook handed it over to the Apache Foundation, and then released a new fork on GitHub a few years later that with a tonne of new dependencies. It'll likely never be merged.
Post reply on HN