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

111–120 of 144 posts

Re: Java EE Is Moving to the Eclipse Foundation

#111

Post by Communitivity »

_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

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, with each command having parameters used to control how it executes. Each build command represents two or more low level commands. There can be some declarative configuration, but the main part of the build is still a program of commands. Examples are Gradle and Rake. In military terms, you dictate individual unit tactics.

* Declarative - The build file is now no longer about entering low or high level commands, it is about declaring your intent, i.e. what you want the build to do. Examples are Lein and Maven. In military terms, this is providing units with Commander's Intent and letting the units do what they do best.

* Predictive - The build file is declarative, but the build ecosystem tracks developer activities and incorporates AI technologies to predict what the user's intent will be, and to inform the user so they are better able to determine their needs. In military terms this is strategy augmented with a Centaur System (a system with both a human and one or more AI components that work together as one entity).

Communitivity, Inc is building Chiron, an Open Source predictive build ecosystem that will be released in 2018. Follow @Communitivity on Twitter for more information in the coming months.

Re: Java EE Is Moving to the Eclipse Foundation

#112

Post by thedudemabry »

Delmania wrote: post #96
_pmf_ wrote: post #91

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

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.

Re: Java EE Is Moving to the Eclipse Foundation

#113

Post by cjsuk »

eecc wrote: post #103
cjsuk wrote: post #51

Earlier quoted context omitted.

It probably would but it won't happen. It's difficult getting anything like that through the layers of purchasing hell. If they provided a web site with pictures of boxes of software for min $2000 that never arrived and didn't do anything it might work better. The moment someone says "donate" the bean counters start sharpening their pitchforks.

How about labelling that button "support" or "maintenance contract"?

That just gets the legal guys on the case.

Re: Java EE Is Moving to the Eclipse Foundation

#114

Post by pjmlp »

cjsuk wrote: post #86
pjmlp wrote: post #85

Earlier quoted context omitted.

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 :)

Except that these cases are not my employer rather some customers.

In any case, I am pretty much against the mentality here that it is to switch jobs just because something isn't nice and shinny at the current employer, or customer.

Not every place on Earth is like SV avid for software developers.

Re: Java EE Is Moving to the Eclipse Foundation

#115

Post by tannhaeuser »

vbezhenar wrote: post #104

What those foundations even mean for projects? Is it like free web hosting or what? Why don't they move to github instead?

It's the gentleman's way to completely unburden maintenance for software not commercially interesting at scale anymore without loosing face as enterprise supplier. Transition to just sounds better than Dumping on github, and upcoming vulnerabilities and other security issues won't make for good media appearance either.

Re: Java EE Is Moving to the Eclipse Foundation

#116

Post by crummy »

_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

I thought Gradle is faster than Maven these days.

Re: Java EE Is Moving to the Eclipse Foundation

#117

Post by tannhaeuser »

needusername wrote: post #33
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…

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.

> Their last JSR (Batch/JSR-352) was particularly disgusting

So a good fit to Websfear then?

Re: Java EE Is Moving to the Eclipse Foundation

#118

Post by sk5t »

tannhaeuser wrote: post #108
sk5t wrote: post #82

Earlier quoted context omitted.

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

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.

Re: Java EE Is Moving to the Eclipse Foundation

#120

Post by mring33621 »

vbezhenar wrote: post #95
alangibson wrote: post #61

Earlier quoted context omitted.

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

XML is not a good interchange format, because it doesn't map well to a standard programming structures. There's no array or map in XML. Developers must use OXM libraries (object to xml mapper). JSON is much more direct and simple format. XML is good for anything that looks like document markup.

I will agree that JSON is 'simple' but it is only 'direct' in the context of javascript. For other languages, it is similar to XML in handling overhead. JSON's significant technical problem is a lack of a formal schema definition and enforcement mechanism. You may feel that this is actually an advantage, but I assure you, as someone who has written systems of record for billion dollar businesses, it is not.
Post reply on HN