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."
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.
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.
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.
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.
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.
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...
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.
> 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.
> "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]
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.
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.
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.
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)
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.
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.
- 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.
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.
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.
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.
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]
> 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.
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.
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.
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.
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).
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!
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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."