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

121–130 of 144 posts

Re: Java EE Is Moving to the Eclipse Foundation

#121

Post by watwut »

jacques_chester wrote: post #77
lockje wrote: post #56

Earlier quoted context omitted.

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

It is not so much that you replace existing project, but more that you start using different technology for new one once you are fed up with old. It makes learning it easier since the bulk of it is the same. Same with hiring people who have experience with different vendor. Also, it gives you shared documentation.

At least that is something that I perceived to be different against js world where exact technology match is often required and documentation weaker.

Re: Java EE Is Moving to the Eclipse Foundation

#123

Post by lovich »

Communitivity wrote: post #111
_pmf_ wrote: post #90

Earlier quoted context omitted.

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

We at Communitivity see build ecosystems as being in one of four phases of evolution: * Instructive - Actual low level commands are basically entered in the build file, with some flow control logic. An example is Make. Ant is another, though Ant straddles the line between Instructive and Imperative. In military terms, you dictate individual unit actions. * Imperative - Build commands are entered into the build file,…

Is this from a poorly trained bot?

Re: Java EE Is Moving to the Eclipse Foundation

#124

Post by jononor »

cjsuk wrote: post #43
strictfp wrote: post #41

Earlier quoted context omitted.

You really drank the coolaid I can see. I think dependency injection frameworks are a bad idea in general, and it seems as if the current trend goes against using them. Also I won't be expecting much good to happen after Eclipse takes over, they tend to complect implementation and not really drive development IMO.

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.

Re: Java EE Is Moving to the Eclipse Foundation

#125

Post by jononor »

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

Earlier quoted context omitted.

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

Some alternatives:

- Make it possible to introspect the state and effects of the code on your dependency in the real implementation, and use that instead of a mock. Can then put the assertion into the code (a post-condition, design-by-contracts style) so it always runs, not just for the few explicitly written unit-tests. Those unit tests can be deleted in favor of something that tests something useful, like running the logic on

- Return the effect (messages to be sent) instead of doing it internally as a side-effect. Then introspect and verify this data in the test. The dependency on the message queue can now be elimitated, both in test and by the complex piece of logic

Re: Java EE Is Moving to the Eclipse Foundation

#126

Post by tannhaeuser »

sk5t wrote: post #118
tannhaeuser wrote: post #108

Earlier quoted context omitted.

Don't get me wrong, I heard good things about Play, but isn't it Scala? Vaadin I know only from a customer of mine who are using it for server-rendered charting apps and I guess it works well in that capacity. And Spring MVC in 2017? Come on. My point being that these frameworks are chosen because the options are limited to what's available on the JVM, trading last-gen Java know-how against younger (and sexier) know-…

Play is for Scala and Java too. Vaadin does much more than charts--although its wrapping of highcharts is pretty nice--and is quite pleasant if you'd rather write Java than HTML and its close relatives. I guess from the Java perspective, Javascript does not look too sexy, as it is a small but dangerous / unhelpful language with an uncompetitive-to-Java library ecosystem. TypeScript is great however.

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

Re: Java EE Is Moving to the Eclipse Foundation

#127

Post by pjmlp »

crummy wrote: post #116
_pmf_ wrote: post #90

Earlier quoted context omitted.

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

I thought Gradle is faster than Maven these days.

Only with the help of a background daemon to catch its data model, a few GB of memory and SSD, to achieve what Maven has doing without daemon help on plain HDDs.

Re: Java EE Is Moving to the Eclipse Foundation

#128

Post by tannhaeuser »

znpy wrote: post #60
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…

A lot of enterprises like to have a solid runtime with proper multi-threading, a comprehensive library set and a stable, well-defined API. Ask yourself why of all the languages and runtime, it's mostly Java running the enterprise world.

But I haven't questioned Java as a backend technology.

Re: Java EE Is Moving to the Eclipse Foundation

#129

Post by pjmlp »

thedudemabry wrote: post #112
Delmania wrote: post #96

Earlier quoted context omitted.

If I remember correctly, Oracle has a licensing scheme if you want to build and release your own JVM. Java SE always has significant more usage in production thanks to Android, Kotlin, Clojure, and Scala. While Java EE does get used a lot in more conservative large enterprises, the alternatives developed to overcome the inherent complexity of EE (Spring, Hibernate) get a LOT more. Java EE is big, but Java SE is even…

Thanks for the explanation. As someone who in a past life developed Java systems (post-2006) for a variety of targets, I was never super clear on what Java EE's value proposition was or how it differed from frameworks that didn't require a separate install. I now gather that it is a collection of helpful packages constituting a framework, but distributed separately from mainline Java core packages.

Java EE was also the cloud, before the term was coined.

When targeting EE application servers, you don't need to worry at all where it is being executed.

As an application, container, bare metal, whatever.

Of course this only works ad long as no native methods or APIs for file or process management are used.

Re: Java EE Is Moving to the Eclipse Foundation

#130

Post by pjmlp »

tannhaeuser wrote: post #126
sk5t wrote: post #118

Earlier quoted context omitted.

Play is for Scala and Java too. Vaadin does much more than charts--although its wrapping of highcharts is pretty nice--and is quite pleasant if you'd rather write Java than HTML and its close relatives. I guess from the Java perspective, Javascript does not look too sexy, as it is a small but dangerous / unhelpful language with an uncompetitive-to-Java library ecosystem. TypeScript is great however.

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

Post reply on HN