15 ms·

Java EE Is Moving to the Eclipse Foundation

192 points by javajocky 9y ago

wener 9y ago
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.
- QuercusMax 9y ago
  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.
annonwhatever 9y ago
Java EE going the way of the Dodo
- andreasgonewild 9y ago
  , 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.
- drama-queen 9y ago
  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.
  - pvg 9y ago
    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.
    - HelloNurse 9y ago
      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.
      - pvg 9y ago
        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.
csours 9y ago
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.
- qwerty_asdf 9y ago
  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/package-summary.html http://docs.oracle.com/javaee/6/api/javax/persistence/packag... / http://docs.oracle.com/javase/7/docs/api/javax/sql/package-summary.html http://docs.oracle.com/javase/7/docs/api/javax/sql/package-s... [1] https://docs.oracle.com/javaee/6/api/javax/servlet/package-summary.html https://docs.oracle.com/javaee/6/api/javax/servlet/package-s... [2] http://www.oracle.com/technetwork/java/javaee/jsp/index.html http://www.oracle.com/technetwork/java/javaee/jsp/index.html
- camus2 9y ago
  > 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.
  - xienze 9y ago
    > 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.
geodel 9y ago
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 https://github.com/oracle
- horusthecat 9y ago
  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.
terminado 9y ago
woah
UK-AL 9y ago
Does oracle have a equivalent?
shagie 9y ago
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."
- jrs95 9y ago
  Doesn't Red Hat have a lot of involvement with Eclipse Foundation stuff as well? Or am I remembering that incorrectly?
  - geodel 9y ago
    Oh yes. Just last month Redhat's Ceylon language became Eclipse Ceylon
  - deleted 9y ago
    [deleted]
- geodel 9y ago
  This is the time when Oracle and IBM both know Java EE is past sell by date. IBM is betting Swift and Go now.
  - georgeecollins 9y ago
    Nothing makes me doubt the future of Swift like this sentence.
    - pjmlp 9y ago
      For IBM one of the pillars of cloud computing is Swift. https://www.ibm.com/cloud-computing/bluemix/swift https://www.ibm.com/cloud-computing/bluemix/swift They used to be one of the main contributors of Swift on Linux.
wocram 9y ago
Isnt the eclipse foundation where projects go to die?
- mibollma 9y ago
  my thoughts exactly when I read that headline.
  - agumonkey 9y ago
    Add me third to that list
- rectang 9y ago
  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.
  - mrmondo 9y ago
    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...
    - nly 9y ago
      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.
deleted 9y ago
[deleted]
rmrfrmrf 9y ago
Does this mean that GlassFish will finally have a chance of not sucking?
- needusername 9y ago
  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.
damagednoob 9y ago
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™.
- needusername 9y ago
  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.
exabrial 9y ago
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.
- strictfp 9y ago
  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.
  - cjsuk 9y ago
    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.
    - lolive 9y ago
      Factory factory factories... ;) http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
      - cjsuk 9y ago
        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.
dfabulich 9y ago
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.
- lockje 9y ago
  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 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.
  - jacques_chester 9y ago
    > 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.
campuscodi 9y ago
Statement from Red Hat: http://middlewareblog.redhat.com/2017/09/12/java-ee-moves-to-eclipse/ http://middlewareblog.redhat.com/2017/09/12/java-ee-moves-to...
- moocowtruck 9y ago
  considering redhat has large stakes on java ee craps i wouldnt expect any other kind of statement
nomercy400 9y ago
So... Java Eclipse Edition?
jerianasmith 9y ago
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.
vbezhenar 9y ago
What those foundations even mean for projects? Is it like free web hosting or what? Why don't they move to github instead?
- watwut 9y ago
  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.
- tannhaeuser 9y ago
  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.
- exabrial 9y ago
  Oddly enough, they're available on GitHub now
puppetmaster30 9y ago
I hope Java 9 Module System moves to Java EE.

192 points by javajocky 9y ago

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.

QuercusMax 9y ago
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.

annonwhatever 9y ago

Java EE going the way of the Dodo

andreasgonewild 9y ago
, 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.
drama-queen 9y ago
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.
- pvg 9y ago
  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.
  - HelloNurse 9y ago
    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.
    - pvg 9y ago
      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.

csours 9y ago

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.

qwerty_asdf 9y ago
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/package-summary.html http://docs.oracle.com/javaee/6/api/javax/persistence/packag... / http://docs.oracle.com/javase/7/docs/api/javax/sql/package-summary.html http://docs.oracle.com/javase/7/docs/api/javax/sql/package-s... [1] https://docs.oracle.com/javaee/6/api/javax/servlet/package-summary.html https://docs.oracle.com/javaee/6/api/javax/servlet/package-s... [2] http://www.oracle.com/technetwork/java/javaee/jsp/index.html http://www.oracle.com/technetwork/java/javaee/jsp/index.html
camus2 9y ago
> 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.
- xienze 9y ago
  > 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.

geodel 9y ago

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 https://github.com/oracle

horusthecat 9y ago
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.

terminado 9y ago

woah

UK-AL 9y ago

Does oracle have a equivalent?

shagie 9y ago

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

jrs95 9y ago
Doesn't Red Hat have a lot of involvement with Eclipse Foundation stuff as well? Or am I remembering that incorrectly?
- geodel 9y ago
  Oh yes. Just last month Redhat's Ceylon language became Eclipse Ceylon
- deleted 9y ago
  [deleted]
geodel 9y ago
This is the time when Oracle and IBM both know Java EE is past sell by date. IBM is betting Swift and Go now.
- georgeecollins 9y ago
  Nothing makes me doubt the future of Swift like this sentence.
  - pjmlp 9y ago
    For IBM one of the pillars of cloud computing is Swift. https://www.ibm.com/cloud-computing/bluemix/swift https://www.ibm.com/cloud-computing/bluemix/swift They used to be one of the main contributors of Swift on Linux.

wocram 9y ago

Isnt the eclipse foundation where projects go to die?

mibollma 9y ago
my thoughts exactly when I read that headline.
- agumonkey 9y ago
  Add me third to that list
rectang 9y ago
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.
- mrmondo 9y ago
  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...
  - nly 9y ago
    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.

deleted 9y ago

[deleted]

rmrfrmrf 9y ago

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

needusername 9y ago
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.

damagednoob 9y ago

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

needusername 9y ago
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.

exabrial 9y ago

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.

strictfp 9y ago
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.
- cjsuk 9y ago
  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.
  - lolive 9y ago
    Factory factory factories... ;) http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
    - cjsuk 9y ago
      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.

dfabulich 9y ago

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.

lockje 9y ago
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 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.
- jacques_chester 9y ago
  > 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.

campuscodi 9y ago

Statement from Red Hat: http://middlewareblog.redhat.com/2017/09/12/java-ee-moves-to-eclipse/ http://middlewareblog.redhat.com/2017/09/12/java-ee-moves-to...

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

nomercy400 9y ago

So... Java Eclipse Edition?

jerianasmith 9y ago

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.

vbezhenar 9y ago

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

watwut 9y ago
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.
tannhaeuser 9y ago
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.
exabrial 9y ago
Oddly enough, they're available on GitHub now

puppetmaster30 9y ago

I hope Java 9 Module System moves to Java EE.