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

71–80 of 144 posts

Re: Java EE Is Moving to the Eclipse Foundation

#71

Post by skissane »

pjc50 wrote: post #67
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.

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

I believe they are positioning it as a replacement for mainframe batch workloads written in JCL, along with rewriting the associated COBOL code in Java. Run WebSphere for z/OS on the same machine as your existing JCL/COBOL batch workload and then slowly rewrite the COBOL into Java and the JCL into JSR-352 JSL, and IBM has Java APIs for VSAM/IMS/etc so you can still access your existing mainframe data from the new Java code. Even if XML is no longer the hotness it was in the early 2000s it is still an improvement on JCL, and it is easier to rewrite batch-oriented COBOL into batch-oriented Java than to change its batch-oriented nature into something more real time.

Re: Java EE Is Moving to the Eclipse Foundation

#72

Post by pvg »

drama-queen wrote: post #11
annonwhatever wrote: post #2

Java EE going the way of the Dodo

JEE is fundamentally a component container spec. The core APIs are sound. Servlets, for example, is a little gem of coherent abstraction. A rethink of the provider/deployment end of the equation for the world of k8 mesos etc. could resurrect it.

Servlets, for example, is a little gem of coherent abstraction

It's a little gem of a memento of Sun's 'write an API for everything in a hurry and hope it sticks' insanity and greed back in the day. The very 'Servlet' interface is supposed to be some sort of generic (possibly stateless) server-side component. All it is actually good for and used for is http, the 'Servlet' interface itself is a completely pointless layer of abstraction.

Servlets are the widely deployed and used standard with multiple high-quality implementations but let's not kid ourselves that the thing itself is some kind of pinnacle of sensible, let alone good API design.

Re: Java EE Is Moving to the Eclipse Foundation

#73

Post by UK-AL »

barrkel wrote: post #63
cjsuk wrote: 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…

"mandating method call order and call count)" - Very few people use mocks like that.

Most people use them glorified stubs for returning data. Personally these days I just in memory datastores.

Re: Java EE Is Moving to the Eclipse Foundation

#74

Post by HelloNurse »

pvg wrote: post #72
drama-queen wrote: post #11

Earlier quoted context omitted.

JEE is fundamentally a component container spec. The core APIs are sound. Servlets, for example, is a little gem of coherent abstraction. A rethink of the provider/deployment end of the equation for the world of k8 mesos etc. could resurrect it.

Servlets, for example, is a little gem of coherent abstraction It's a little gem of a memento of Sun's 'write an API for everything in a hurry and hope it sticks' insanity and greed back in the day. The very 'Servlet' interface is supposed to be some sort of generic (possibly stateless) server-side component. All it is actually good for and used for is http, the 'Servlet' interface itself is a completely pointless la…

Calling the Servlet interface "a completely pointless layer of abstraction" only because in practical use nobody ever cared for anything but HttpServlet is unfair. It's a reasonable, natural and correct abstraction that, at the very least, helps distinguishing HTTP specific features from general purpose ones.

Re: Java EE Is Moving to the Eclipse Foundation

#75

Post by barrkel »

UK-AL wrote: post #73
barrkel wrote: post #63

Earlier quoted context omitted.

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…

"mandating method call order and call count)" - Very few people use mocks like that. Most people use them glorified stubs for returning data. Personally these days I just in memory datastores.

I have seldom seen a jMock Expectations clause without oneOf etc.

Re: Java EE Is Moving to the Eclipse Foundation

#76

Post by pvg »

HelloNurse wrote: post #74
pvg wrote: post #72

Earlier quoted context omitted.

Servlets, for example, is a little gem of coherent abstraction It's a little gem of a memento of Sun's 'write an API for everything in a hurry and hope it sticks' insanity and greed back in the day. The very 'Servlet' interface is supposed to be some sort of generic (possibly stateless) server-side component. All it is actually good for and used for is http, the 'Servlet' interface itself is a completely pointless la…

Calling the Servlet interface "a completely pointless layer of abstraction" only because in practical use nobody ever cared for anything but HttpServlet is unfair. It's a reasonable, natural and correct abstraction that, at the very least, helps distinguishing HTTP specific features from general purpose ones.

How is it unfair? The fact that nobody uses it and that it has found no use for the decades it's been around is the very definition of 'pointless layer of abstraction'. It was written in a period of an API land grab. A reasonable and natural thing is to be suspicious of an abstraction that has no use or precisely one real use.

Re: Java EE Is Moving to the Eclipse Foundation

#77

Post by jacques_chester »

lockje wrote: post #56
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.

Many of the open source libraries are concrete implementations of the Java EE specs. Hibernate uses JPA, GUICE standarized the CDI implementation ( http://googlecode.blogspot.nl/2009/05/javaxinjectinject.html ). And many of the technologies offered by Java EE are standarizations of concepts. This is highly valueable for reuseability and not having 10 libraries completely reinventing the wheel.

> This is highly valueable for reuseability and not having 10 libraries completely reinventing the wheel.

This was a problem in the days when the only available platforms were closed-source. Standardisation was pushed onto vendors by buyers in an attempt to weaken their lockin power. It never really worked very well. No matter how flawless the standard, no matter how miraculously identical the behaviour of the implementations, nobody is going to bet their career on a move that bets the company on a different vendor. Too expensive, too risky, too long.

OSS changes that equation entirely. Say you pick Guice. Will Google behave like Oracle and extract everything up to one dollar less than your "fuck this, let's migrate" price?

They can't.

Say you pick Spring. Will Pivotal burst through the door demanding licensing fees, support fees, sales fees, fee-collecting fees, fees to the power of fees, also à la Oracle?

They can't.

So you're left with technical lockin. Which you always had anyway.

The economics have changed. For libraries, for code running inside a single process, standards are now largely irrelevant, because you'll rely an OSS framework or library in which there is no risk of vendor lockin.

The frontier of standardisation has moved to formats and network protocols. The most widely-used network protocols actually foreshadowed the triumph of opensource.

Similarly, file formats we've all pretty much settled on a handful of open formats for the vast majority of greenfield and brownfield integrations.

These protocols and formats have standards, but as a guide to cooperators, not as a shield against vendor bloodsucking.

Java EE matters a lot, insofar as the majority of Java code written somewhere passes through a JEE-defined interface. But it no longer controls the destiny of Java programmers. That now lies with the OSS contributors and their sponsors.

Disclosure: I work for Pivotal, we sponsor Spring.

Re: Java EE Is Moving to the Eclipse Foundation

#78

Post by wiz21c »

pjc50 wrote: post #67
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.

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

Not sure of what you mean, but batch processing is still pretty useful. I happen to work on a project which has batch running 10 hours a day, processing complex business cases, calling dozens of web services, etc. This could absolutely not be made in real time.

Or maybe you said that 1970's batch were inferior to today's batch. In which case I'd be happy to read what non-superficial differences exist...

Re: Java EE Is Moving to the Eclipse Foundation

#79

Post by StevePerkins »

pjc50 wrote: post #67
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.

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

I have not reviewed that JSR, so I have no comment on the merits of its implementation.

However, it's worth pointing out that MOST tech concepts people regard as "modern" today are actually re-treads of 1970's ideas.

Re: Java EE Is Moving to the Eclipse Foundation

#80

Post by cjsuk »

UK-AL wrote: post #73
barrkel wrote: post #63

Earlier quoted context omitted.

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…

"mandating method call order and call count)" - Very few people use mocks like that. Most people use them glorified stubs for returning data. Personally these days I just in memory datastores.

We do use mocks like that. How else do you test that a complex piece of logic doesn't try and perform the same operation twice, such as a trivial case of sending only one message to a queue?

Without the assertion, you are left with an assumption, which from experience isn't reliable and keeps you up at night.

Post reply on HN