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

131–140 of 144 posts

Re: Java EE Is Moving to the Eclipse Foundation

#131

Post by tannhaeuser »

pjmlp wrote: post #130
tannhaeuser wrote: post #126

Earlier quoted context omitted.

> uncompetitive-to-Java library ecosystem React, Webpack, CSS compilers and pretty much all other modern frontend (compile-time) asset tools are running on Node.js and install from npmjs.com. Node.js is also perfect for a shallow web-facing container developed along with the front-end as a complement to Java-based (mini/SOA/whatever)-services. So I think it's quite useful to make Node.js workloads run under the JVM.

When we talk about rich libraries we mean actual libraries for generating PDFs, reading barcodes, report generation, talking with all kinds of enterprise databases, GPU programming, parallel distributed algorithms, embedded development... Not yet another packaging tool or fait-divers like pad left. And the majority of them written in pure Java, not C++ wrapped in a JavaScript API.

> When we talk about rich libraries we mean actual libraries for generating PDFs

I was specifically talking about web libraries/tools, though. Nobody is saying Java backend development must be abandoned in general.

Re: Java EE Is Moving to the Eclipse Foundation

#132

Post by needusername »

_pmf_ wrote: post #91
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.

> 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. That's strange. How do they make money off SE but not EE? EE has been the cash cow that kept Java alive after applets fell out of favor.

> EE has been the cash cow that kept Java alive after applets fell out of favor.

I have no insight into Oracles reasoning or finances, I can just see their actions. While I assume they make money off WebLogic licenses I can't image that revenue is growing in the double digit range per year. I assume that Oracle as a publicly traded company is forced to produce growth numbers. These days that's could. They probably some imagine to provide some sort of Java could, that would explain why they pushed so hard for Jigsaw. This doesn't really have make sense to you and me, just to Oracle execs.

Re: Java EE Is Moving to the Eclipse Foundation

#133

Post by needusername »

exabrial wrote: post #40

This is awesome. CDI, JAXRS, JPA, JTA, and JMS are brilliant technologies but are held down by the weight of legacy technologies. Maybe we can finally see Java EE based solely on CDI, which would kick every platform out of the water. Scopes take dependency injection to the next level and finally fulfills the promise of modular, testable, reusable code.

> CDI, JAXRS, JPA, JTA, and JMS are brilliant technologies but are held down by the weight of legacy technologies.

JMS is not a brilliant technology. It gets stuff done but it's not brilliant. Issues I have with JMS:

- There is the old API which is closely modelled after JDBC, quite verbose, many objects that you have to close (not that bad anymore since Java 7) and checked exceptions. You almost never want to work with this API directly but use some convince layer above it. For example something like Spring JdbcTemplate, unfortunately Spring JmsTemplate hasn't received any love and therefore doesn't support generics or functional interfaces. I have a PR open for this but nobody seems to care about JMS anymore. But at least the old API works with connection pooling.

- There is the new API (JMSContext) which is much nicer to use, much less verbose and uses runtime exceptions. Unfortunately the new API does not work well with connection pooling. That's why Spring doesn't support the new API. That was supposed to be fixed in JMS 2.1 (https://github.com/javaee/jms-spec/issues/126) but then Oracle cancelled JMS 2.1.

- The old and new API from above are both part of JMS 2.0. In addition some methods you can only call when running in Java EE, some methods you can only call when running in Java SE, and some methods you can call from both Java SE and EE. We're talking about methods on the same interface here. How can you tell which ones you can call? If you're lucky it's mentioned in the method comment, that should now be the case for most of the methods since JMS 2.0, otherwise you just have to know about the inner workings of JMS and Java EE.

- JMSException#getCause() is unspecified. Only JMSException#getLinkedException() is specified. Yes, Java 1.4 Exception#getCause(). Which means if you have some generic exception handling code that uses Exception#getCause(), like let's say a logger framework that renders stack trace, then that code is only guaranteed to work if it special cases JMSException. That was also supposed to be fixed in JMS 2.1 (https://github.com/javaee/jms-spec/issues/113) but then Oracle cancelled JMS 2.1.

- The only way to receive messages without blocking is to use an MDB. Unfortunately MDBs have to be pooled. In addition there is no portable way to connect an MDB to a non-default RAR in your application server.

Sure, JMS solves problems but brilliant it is not.

JAX-RS even has it's own component and DI model different from CDI because of NHI syndrome.

Re: Java EE Is Moving to the Eclipse Foundation

#134

Post by pjmlp »

tannhaeuser wrote: post #131
pjmlp wrote: post #130

Earlier quoted context omitted.

When we talk about rich libraries we mean actual libraries for generating PDFs, reading barcodes, report generation, talking with all kinds of enterprise databases, GPU programming, parallel distributed algorithms, embedded development... Not yet another packaging tool or fait-divers like pad left. And the majority of them written in pure Java, not C++ wrapped in a JavaScript API.

> When we talk about rich libraries we mean actual libraries for generating PDFs I was specifically talking about web libraries/tools, though. Nobody is saying Java backend development must be abandoned in general.

How do you generate a PDF on such a cool JavaScript front end application?

Hint, you don't. Just hope that the browser does a good job with print to PDF, or run a server side pile of shell scripts, using LaTeX and Postscript, instead of a plain simple library.

And this is just one example from many, where JavaScript/Web sucks on the front-end.

Also Android is front-end development.

Re: Java EE Is Moving to the Eclipse Foundation

#135

Post by needusername »

damagednoob wrote: post #34

Not sure if I'm mistaken but isn't the major thing about this the TCKs? As far as I'm aware they are the keys to kingdom for alternative Java implementations. Never shared by either Sun or Oracle so if and when this happens it will be a good thing™.

You're correct. In the old days that was the case. They were shared but only for money. These days Tomcat, TomEE and Payara can't claim Java EE compliance because they don't have a TCK. It is not clear to me wether this would also retroactively include the Java EE 8 TCKs. It is important to note that Oracle does not transfer the Java EE brand name. So whatever comes out of Eclipse can't be named Java EE 9. You can't make this stuff up.

Re: Java EE Is Moving to the Eclipse Foundation

#136

Post by cjsuk »

jononor wrote: post #124
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.

Stop putting code and data into the same object. It encourages way too stateful code and lots of cross-dependencies between code components. Pass around plain-old-data instead and the need for dependency injection is much less needed, just inject data instead when testing. And stop adding abstractions premptively, YAGNI.

These classes all sling value objects around. That's a separate thing.

Re: Java EE Is Moving to the Eclipse Foundation

#137

Post by lolive »

UK-AL wrote: post #99
cjsuk wrote: post #80

Earlier quoted context omitted.

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.

Because it makes refactoring very difficult. One of the original intentions of TDD and Unit testing was to make refactoring much easier. If you start testing the internals of function, it makes it very difficult to refactor without breaking tons and tons tests. We only test on publicly exposed functions, and check the changes on the data or external services. It means we can do major refactoring's of internals, keep…

I don't disagree with your explanation. But the core point of objects is to bind a state and some method implementations.

Mocking the state sounds mandatory to test the method implementations in such a paradigm.

What you propose seems more like functional programming oriented testing.

Re: Java EE Is Moving to the Eclipse Foundation

#138

Post by hacking_again »

bm98 wrote: post #107
hacking_again wrote: post #100

Earlier quoted context omitted.

Wow, after 15 years or whatever it is, I never made the connection between Eclipse and Sun!

> "According to Lee Nackman, Chief Technology Officer of IBM's Rational division (originating in 2003) at that time, the name 'Eclipse' (dating from at least 2001) was not a wordplay on Sun Microsystems, as the product's primary competition at the time of naming was Microsoft Visual Studio, which Eclipse was to eclipse." [1] [1] https://en.wikipedia.org/wiki/Eclipse_(software)#Name

Haha yes, don't bite the hand that feeds you.

Re: Java EE Is Moving to the Eclipse Foundation

#139

Post by vorg »

_pmf_ wrote: post #90
mseebach wrote: post #69

Earlier quoted context omitted.

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

> No offense to Groovy

Groovy (on the JVM) joined the Apache Software Foundation 2 years ago after being ditched by VMware/Pivotal. Like the EF, the ASF is another place where software goes to die -- Apache Groovy and Eclipse Ceylon. There's nothing wrong with the original premise of Groovy being a lightweight dynamically-typed scripting language for the JVM, by adding closures to Beanshell. But along the way it got plagued by feature-creep and leadership problems, and started trying to compete with statically-typed languages like Java and Scala. It's only real widespread use nowadays is for writing 20-liner build scripts for Gradle in Android Studio. As for Grails, no-one's upgrading their old version 2 projects to version 3, or starting new projects in it.

Re: Java EE Is Moving to the Eclipse Foundation

#140

Post by exabrial »

needusername wrote: post #133
exabrial wrote: post #40

This is awesome. CDI, JAXRS, JPA, JTA, and JMS are brilliant technologies but are held down by the weight of legacy technologies. Maybe we can finally see Java EE based solely on CDI, which would kick every platform out of the water. Scopes take dependency injection to the next level and finally fulfills the promise of modular, testable, reusable code.

> CDI, JAXRS, JPA, JTA, and JMS are brilliant technologies but are held down by the weight of legacy technologies. JMS is not a brilliant technology. It gets stuff done but it's not brilliant. Issues I have with JMS: - There is the old API which is closely modelled after JDBC, quite verbose, many objects that you have to close (not that bad anymore since Java 7) and checked exceptions. You almost never want to work w…

> There is the old API which is closely modelled after JDBC

Pretty much, exactly my point about "weight of legacy technologies" :D

> JAX-RS even has it's own component and DI model

Yep, CDI and JAX-RS came out in separate JSRs. JAX-RS 2.0 could pretty much be written on top of CDI however

Post reply on HN