Hacker News new | past | comments | ask | show | jobs | submit login
Java EE Is Moving to the Eclipse Foundation (adtmag.com)
192 points by javajocky on Sept 12, 2017 | hide | past | web | favorite | 139 comments

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 manage it and said "ok - you can do it."

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.

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.

> Maven -> Gradle

Given that my Maven builds run circles around the Android Gradle ones, and that it is still a session subject at Google IO, I hardly see that as progress.

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.

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.

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.

Is this from a poorly trained bot?

Ouch. Well, live and learn. It would be nice though if one or two of those who down-voted me explained why my comment was objectionable, so at least I can avoid a repeat of whatever mistake I made.

The comment only very tangentially touches on the subject matter of the GP. Crucially, it seems to suggest that Maven is at a higher "phase of evolution" than Gradle (which is anachronistic) which is the opposite of both the GP and my original claim. A valuable contribution might be to explain why Gradle belongs at a lower level of evolution from Maven.

Further, the comment is written in a pretty grating marketing-style: "We at Communitivity see build ecosystems..." and ends by plugging a product. Also, military analogies are pretty weird when addressing an audience of people who on average have substantially more experience with build systems than with military command structure.

I looked at your comment history, and this is not how you write. (Also, more of a curious aside, you've had a profile with that name for 6.5 years, and this comment seems to be the first record of you being a plural "we" launching a product?). You clearly understand the style of this community and how to contribute, and should not need explaining why copy-pasting an only barely not-off-topic marketing blurb would be unpopular.

Thanks for replying and explaining the down vote. I'm a DoD contractor for now, and I think what happened regarding the marketing style is that I was still in my 'office' voice, which is by nature always marketing, and I was also talking about a product I am excited about. I know it's hard to believe, but that was actually typed out, not copy pasted. DoD contracting is a different world and when there I have to write like that..my brain just hadn't clicked over from a DoD mindset to a startup mindset.

Which is ironic, because a good chunk of my success as a contractor is improving DoD projects I work on by applying the stuff I've learned from the startup community through HN, blogs, and friends doing startups.

You are also right regarding evolution, it's not the right word and I should have taken the time to come up with the right word - since it can't be evolution as Gradle came after Maven. Also, I was responding to a comment thread that had already started to drift from the GP to be on Maven vs. Gradle, and shouldn't have drifted it further.

To answer your question on the profile.. I had an aborted attempt to do a startup when the company I was with changed their IPR terms at the same time my parents died, and I wound up putting that dream on the shelf until I left that company. For various reasons (family medical costs among them) I wasn't able to go all-in 100% on my startup.

I appreciate the help, and will make sure I change hats before commenting in the future. To end on a smile, I'll show why this will be harder than you might think. Writing the first sentence I had a brief moment where I was about to type "Your help is greatly appreciated. I'll ensure my comments are of higher quality in the future, and carefully consider the content of future postings". Then I realized I was doing it again.

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.

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.

Sometimes your actual data doesn't map well to "standard programming structures". If that's the case, you really want your interchange format to express reality as far as possible, not how it will be processed in any particular program. I don't have enough experience to be authoritative here, but this seems like a bad argument.

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.

Someone is finally saying this.

Plus, there is a ton of things that json can't do or isn't supposed to do (things like defining a grammar, xpath, xquery, xslt and a lot more)

I'd rather write brainfuck for a living than the abomination xslt is.

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.

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.

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

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

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.

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

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

So a good fit to Websfear then?

This is the time when Oracle and IBM both know Java EE is past sell by date. IBM is betting Swift and Go now.

Nothing makes me doubt the future of Swift like this sentence.

For IBM one of the pillars of cloud computing is Swift.


They used to be one of the main contributors of Swift on Linux.

Now IBM just needs to obtain cloud customers to support said pillars...

Poor ole big blue has seen better days...

Watten Buffet even wrote it off.

eh, Swift Runtime is a IBM product and not community. Go is community btw, and they do have a couple of other IBM and community runtimes avail[0].

[0]: https://console.bluemix.net/catalog/?cm_mc_uid=5252549325751...

I don't understand. What companies that are targetted by Java EE supposed to use in the future?

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.

Even more curiosly, Sun never saw a full solar eclipse in the US

Doesn't Red Hat have a lot of involvement with Eclipse Foundation stuff as well? Or am I remembering that incorrectly?

Oh yes. Just last month Redhat's Ceylon language became Eclipse Ceylon

I would argue that Pivotal has beaten both of them with Spring.

Few years back I wouldn't have doubted but today I am not so sure that adding layers of Java framework for all base technologies is sure shot way to win.

I'd like to note here that Spring being popular doesn't mean it's good. Also see: nodejs

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.

> 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

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.

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 out depending on who paid for what.

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.

Call order and count assertions are important in non-idempotent calls (message delivery for example) and complex integration tests.

While I respect your opinion, it misses three realities. Firstly you can't generalise most complex systems enough for this to be a viable solution universally. Secondly, skill level just isn't on the market to implement this for every case even if you could specify it. Thirdly, to solve the first two problems it costs more.

Data flow moves all the test responsibilities into integration testing, which is much harder!

It's a careful thing to balance but I'm currently on the side of mocks and control flow based systems. They are cost effective and scale well in practice (I think we're on about 4 million or so lines of code and tens of thousands of class levels now)

I think "realities" are subjective here :)

Complex systems only become tractable when modularized, and simple module boundaries are preferable to chatty APIs; the nature of the system may make it more or less worthwhile, I'll agree.

Building crappier software because that's all you can build with the people you can find seems to me to be putting the cart before the horse. And I think you easily end up with crappier, less flexible software if you blindly follow Java norms. The tendency to over-specified tests both increases the cost of writing test code, increases the cost of refactoring (the tests usually need to change in some proportion to the implementation, even if the behaviour is no different), but even worse: your modules are, by default, not recomposable. When things are built out of data flow instead of control flow, you get a bunch of power almost for free.

Parallel and distributed processing, logging and system introspection, up to and including new product development using known good components. The business agility is especially important.

I've seen codebases calcified by "long land borders" between modules, with value locked in by the architecture, requiring risky and costly refactoring, rewrites or monotonically increasing complexity to try and repurpose that value. A system that looks more like Lego than a series of custom crafted blocks is more valuable, even if it's harder to build.

The opportunity cost obviously depends heavily on the domain. For an internal corporate IT project, I can certainly see that the upside isn't as clear.

"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

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 public functions the same but tests will still pass.

One of the biggest mistakes that happened was that kent beck was misinterpreted and Unit was considered a code unit, when really it means a unit of behaviour.

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.

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

Bet on a software engineering blog to try to make a point using bad paralels with, uh, murdering women.

I do believe that's actually a personality cult disguised as a software engineering blog

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.

As long as you program in Java DI is the best option you have if you want your code to be unit-testable.

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.

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.

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.

considering redhat has large stakes on java ee craps i wouldnt expect any other kind of statement

Isnt the eclipse foundation where projects go to die?

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

Once there, lots of stakeholders are more comfortable committing lots of resources because the governance rules are predictable and well understood. So the projects tend to cater to those stakeholders, putting a higher emphasis on backwards compatibility and evolving more through extension than through revolutionary, breaking changes.

Projects which go to foundations live for a long time. And they don't stop innovating, either -- they just innovate more at the edges than at the core.

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.

my thoughts exactly when I read that headline.

Add me third to that list

Can someone explain what Java EE really means? I tried to parse the bundle and license the last time this came up, and I didn't really get anywhere.

It means the whole server-side JDK API, including the servlet spec, jsp libs and JDBC SQL framework under the javax.* packages, whether actually distributed as part of the JDK or not. [0,1,2]

[0] http://docs.oracle.com/javaee/6/api/javax/persistence/packag... / http://docs.oracle.com/javase/7/docs/api/javax/sql/package-s...

[1] https://docs.oracle.com/javaee/6/api/javax/servlet/package-s...

[2] http://www.oracle.com/technetwork/java/javaee/jsp/index.html

> Can someone explain what Java EE really means? I tried to parse the bundle and license the last time this came up, and I didn't really get anywhere.

It's no different than Web standards between browsers, it's a collection of API specifications describing how web applications should be architectured in Java. Then different libraries can follow the spec. JavaEE also has a reference implementation which used to be done by Sun/Oracle.

The problem with JavaEE is, by being too broad and generic, it is incredibly complex and often fails to solve today's developers problems. I mean who cares about JSF(java server face, a way to describe "HTML GUI widgets" in XML) when most applications use a RESTful architecture? Beans session persistance? ... JEE has a lot of technical debt, the word is definitely appropriate here.

> I mean who cares about JSF(java server face, a way to describe "HTML GUI widgets" in XML)

Well, a lot of people did because once upon a time that's how we wrote applications (primarily via server-side rendering).

> when most applications use a RESTful architecture?

Java EE has an API for that...

> JEE has a lot of technical debt

Can't argue with that, but it comes in the form of APIs you don't have to use.

Most enterprise shops do care about JSF.

I know of many greenfield projects using it, mainly PrimeFaces.

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 who can't or don't want to invest into JavaScript or another web stack, but I think a responsible consultant should tell these customers that their stack is on life support now.

A lot of enterprise companies aren't buying in JS frameworks because the velocity of those frameworks is too fast. I kind of agree. When you have 50,000 desktops, a 6 month lead dragging a pile of apps over to a new browser is a nightmare scenario. All it takes is one app which the vendor doesn't give a shit about and one internal app deprecating an IE version used by 50 users due to a JS framework change in a branch office and there's a headache from hell on your plate.

Fortunately they're all starting to kick out chrome for business now.

Maybe for those customers it might make sense to donate to the Eclipse foundation to keep JSF etc. alive and to keep Java-only devs afloat? But then maintenance of J2EE has ceased because it's not economically feasible.

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.

We have customers were using Chrome is a security risk, because they cannot control its deployments like on FF, IE and Edge.

Fortunately that excuse is no longer valid as they have GPO templates, MSI packages, the lot: https://support.google.com/chrome/a/answer/7358568

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.

Most of those companies use AngularJS for that specific reason. It's stable, well tested and documents, and it works.

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

Our Java tools keep giving us a full stack.

Talking about fads, the so modern JavaScript frameworks now have discovered how to optimize user experience on mobile by doing, guess what, server side rendering!

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

It's also a miracle to me why JavaScript isn't more popular with Java developers, of all people, when in fact Java has two mature JavaScript engines, and JavaScript certainly is interesting from a bridge/migration perspective. Years ago Oracle and RedHat had even partial Node.js ports, but it never went very far.

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.

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

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.

It's basically Java SE + a standarized stack of technologies, that are usually used in server applications: Servlet, EJB, CDI, JSP, JSF, JTA, JPA...

Java EE is not the only way of doing serverside java apps - most of systems i've developed used tomcat + spring-* stack, which is not a Java EE platform.

I think reading this project page may help clarify what Java EE is:


Spring + tomcat is built on J2EE, or at least it was 5 years ago when I worked on that stuff. The servlets API is part of J2EE.

The whole "Spring is really JEE" retort is even more pedantic than the folks who insist on referring to "Linux" as "GNU/Linux".

These days it's more fair to say that Spring "supports optional integration" with JEE API's. You can run modern Spring web/REST apps without a Servlet container. Spring doesn't care whether your ORM implements the JPA interfaces or not. Etc, etc... it's all slowly phasing out.

Many of the annotation based APIs from Spring are actually JEE as well.

You can think of it as a standardized API for creation of enterprise web applications.

the more esoteric corners of Java. It's like someone just offered to support windows XP forever. I highly recommenced donating to the Eclipse Foundation, they have made an impact far out of proportion to their size close to Bill Gates, but what they're doing for the good of us all might not be profitable.

There's nothing esoteric about Java EE at all, what are you talking about? It has, among other things, the standard API for creating REST services, data binding via XML and JSON, persistence, etc.

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.

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.

Governance. Github would be just free hosting + tracker.

The other thing is, emerging expectation that all open source projects should be stored in one place (Github) is not a good development. Puts too much power in hands of a single company.

Oddly enough, they're available on GitHub now

Java EE seems drag on Oracle's cloud future. One can see where Oracle would like to focus, at least, through their open source efforts [1].

1. https://github.com/oracle

I heard some scuttlebutt about two years ago after Oracle got rid of some Java people that Oracle had wanted to leverage Java-as-a-Service as a cloud product, sort of like Google Compute, but just never managed to get there... The Sun acquisition, someone told me, "was a hardware acquisition". With SPARC/Solaris dead, Sun staff gone and the lawsuits against Google over Java faltering Oracle has sucked the last marrow out of the bones and is just casting them off now.

Does this mean that GlassFish will finally have a chance of not sucking?

Yes, if the Payara guys manage to take over the project, do more frequent releases and pull off some major refactorings. I am not sure they have the resources.

Its' true that there's no array or map in XML, but Arrays can be serialized to XML. I too haven't reviewd JSR, So not in position to say about implementation.

So... Java Eclipse Edition?

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.

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.

, and not a second too early. Definitely cause for celebration!

Edit: Sore toes, anyone? Too invested to see clearly? I did enough EE-consulting to have an opinion; it's over-engineered, marketing-driven bullshit; designed to make everything as complicated as possible.

I hope Java 9 Module System moves to Java EE.

Does oracle have a equivalent?


Feel sad, don't like things goto Eclipse. Eclipse makes me feel less techs, maybe the bad impression from eclipse, these bad impression last for at least five years, most of time someone get into the trouble is caused by eclipse, feel more worse.

Are you confusing Eclipse-the-IDE with Eclipse-the-Foundation? The Eclipse Foundation is much like the Apache Foundation - the piece of software it was originally named for doesn't have much to do with lots of the projects hosted / owned by the foundation.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact