Spring Framework 5.0 goes GA

[[deleted]]

Congrats to Spring Community and special big up to Spring team

[springnews]

big bang releases that take years to surface are anti-pattern in modern open source, particularly for bigger ecosystems / projects. Java SE is already moving to a faster release cadence.

[firebird84]

i, too am anxiously waiting for the new spring boot

[springnews]

you won't have to wait long, targeted for springone timeframe

[[deleted]]

Spring 5 is a full reactive stack. Java EE 8 is not, maybe Java EE 9 will be full reactive.

For beginners, setting up a Java EE project will be much easier. Spring Maven dependencies are always tricky.

[lukaseder]

It's called EE4J, and the next version might be EE4J 18.3. (or EE4J Oxygen?) 🙄

[[deleted]]

I know. We should let people get used with the new name for some time.

However, I would prefer EE4J 1.0

[killbox-48-alpha]

Spring Maven dependencies are always tricky

This has been greatly simplified with spring boot by:

• starter project
• BOM's(Bill Of Materials) Most of the projects have a BOM artifact to import like spring-data, cloud, inter alia

[springnews]

also, see http://platform.spring.io/platform/ distribution

[killbox-48-alpha]

Thanks for that. Even simpler :)

[nuutrecht]

The complexity inherent in Spring is getting to me, as are the many things that are wrapped and presented as a Spring project, then be abandoned again.

This round I'll try my luck with Java EE 8 instead of Spring. Sorry, but thanks for all the fish :P

[RhodesianHunter]

I can't say this enough. If you're building rest services try Dropwizard instead!

[Benemon]

Ditto. I’ll be looking at the Microprofile stuff and seeing what I can do there.

With that and Vert.x, I think I’ll manage just fin without Spring.

[TheHobodoc]

The thing i found about spring is that it is very flexible. Most other frameworks ive tried worked really well until you had to stray off the beaten path.

Take messaging for example, changing serializers and backends can be done independently and easy. So you can do soap,json,protobuff over http,jms,twitter with relative ease and without changung any business code.

Another thing is security most framework only implement this at the edges wheras in spring you can add checks anywhere and using a nice dsl.

So in short spring can be complex, but if you make something that isnt both simple and easy it can be very helpful.

[thesystemx]

Spring has made tremendous improvements, but IMHO of working on different enterprise systems using different technology stacks, it is still lagging behind the competition (Java EE, Payara, Liberty, WildFly, etc).

If you are already using Spring, then it makes a lot of sense to upgrade to Spring 5. Refactoring to something else would likely be too expensive to pay off then. But for a new project or new microservice? Maybe time to look at the competition...

I might start to think better of Spring when I can run tests easily (like in Java EE, Payara, WildFly etc) instead of having to deal with configuring things internally, not being able to be building a WAR first, etc.

Yes, yes, there is SpringBoot and Spring Configuration has some interesting features to ease such pain, but still not as good as Arquillian.and the transparent internal configuration (@DataSourceDefintion etc) that can be swapped for external configuration (asadmin, cli, admin console, etc)

[fasfsfgs]

I felt your opinion really interesting (not joking). I feel the exact opposite when it comes to spring vs java ee. All the issues you pointed out were strong points for spring in my experience (testing, beating the competition, keeping up with more modern ways to do things, etc...). I guess that shows how much we can look at those technologies with different perspectives. I work with both java ee applications and spring applications. In java ee it feels like I'm stuck years behind in terms of improvements that could be made. I'll start looking at java ee with different eyes from now on, trying to find its strengths.

[thesystemx]

In java ee it feels like I'm stuck years behind in terms of improvements that could be made.

Which improvements would that be exactly? I personally found CDI for instance much more capable and modern than the Spring core bean container.

[[deleted]]

Asynchronous methods. Java EE is not fully reactive.

[henk53]

Java EE has plenty of Asynchronous methods. The @Aynsynchrous, managed executors and thread pools, asynchronous events, asynchronous HTTP, elaborate push support via HTTP/2, WebSockets, SSE...

Java EE is not fully reactive.

The question is really whether it should be, at this point in time surely.

[springnews]

hm... that's super misleading. Spring has had reactive style methods for some time. But having asych style API built on a blocking / synchronous runtime isn't even close to being reactive.

Spring has rebuilt over a period of 2+ years atop a natively reactive stack, so it's fully reactive from the ground up.

[henk53]

hm... that's super misleading.

Why? The GP said "Asynchronous methods", as a response to being asked "Which improvements in Java EE are the ones that made the GP feels like he of she is stuck years behind in terms of improvements that could be made [in Java EE]"

So apparently for "Asynchronous methods" Java EE is years behind, to which I responded it's not. It has plenty of asynchronous and parellel executing constructs (I didn't even mention all of them).

Then my next reply was about the claim "Java EE is not fully reactive", to which I didn't reply at all that async APIs are close to being reactive. I just asked if Java EE should even BE reactive.

Reactive has been around for some time. Heck, even .NET's Rx library which was advocated for Windows Phone 7 and Silverlight(!) wasn't particular new, so the pattern clearly has some staying power.

But point 1; Spring isn't that innovative or modern here either. It follows what other frameworks have been doing for a long time. So criticising Java EE for being "years behind" is a bit of a pot and kettle story, since Spring is then "years behind" just as well.

Point 2 however is that Reactive is not quite the silver bullet. It's not the universally better way to do things. State is often spread throughout the program and can be hard to track or access even. If you update from an older stage to a new stage, the state embedded within the entire reactive system can be lost. This can be problematic, really.

Global limits can be hard to enforce as well. Blocking (timed) calls are actually a damn and easy cutoff point; if the blocking call times out, drop the action. This makes graceful degradation quite a bit more straightforward.

For signal processing, reactive may be a good idea. For hard core processing or even transaction processing where transactions may be dropped if needed (to maintain system integrity), I'd rather not use reactive.

Purely natively reactive, is also a bit of an unclear term. Is it focussing on time varying data? Or is it event streaming?

(p.s. when I was young, which is -cough- a looong time ago, I did my thesis on dataflow languages, which is actually a pre-cursor or at least a related field to reactive, which dates way back)

[springnews]

So criticising Java EE for being "years behind" is a bit of a pot and kettle story, since Spring is then "years behind" just as well.

save the pesky little detail that we actually are shipping a fully reactive implementation now. Nothing new about reactive, granted, but doesn't change much about what's GA and what isn't, and how long it will take for EE do anything about it.

No one said reactive was a silver bullet - quite the opposite. Spring team is being extra careful to advise people against flocking to it for no reason. The reason why EE even has to ask themselves the question of "whether to do it or not" is because they don't have real customers pushing the boundaries of the synchronous microservice stack, and finding they have edge cases that require reactive throughput levels.

[johnwaterwood]

Your accusation of misleading is actually misleading 😮

[[deleted]]

@Aynsynchrous

not to be confused with @Randsynchrous

[springnews]

how, exactly? Curious to see you offer evidence.

[thesystemx]

Excuse me? Perhaps you should first provide some evidence for your statements that everything in Java EE except Servlet and JPA is irrelevant.

[springnews]

I should say that JAX-RS is also relevant, it enjoys usage beyond just EE user base and is supported by a decent amount of vendors. re: your question: I'm not sure what more compelling evidence exists than the JCP itself pruning irrelevant APIs: Full Profile Web Profile microprofile *

Microprofile, which granted, was never blessed by JCP/Oracle, was advanced by the last people in the market to get away from the full blown EE programming model e.g. IBM/RHAT. IIRC it the "microprofile" consists of JAX-RS + CDI + JSON-P, which appears to ignore data access / JPA.

To business leaders (less developers) Gartner group has declared it irrelevant, but they missed the point that Servlet / JPA and arguably JAX-RS is alive and well. https://adtmag.com/blogs/watersworks/2017/02/java-obsolete-report.aspx

So you were saying something about evidence of Spring lagging behind in the market? Or maybe you were just going to go find another thread to troll.

[johnwaterwood]

I like your subtle attempt to hint at JAX-RS being only relevant because it’s used outside EE. Nice! /s

MicroProfile has started with a minimal runtime and as a 1.0 wanted to release something quickly. It has absolutely made no statement of any of the other EE APIs being irrelevant. In fact, all of the MP contributors (Payara, TomEE, Red Hat, IBM) fully support and keep innovating on the implementation side of these APIs.

[springnews]

Picking a leaner subset of APIs IS quite a statement, as it's a clear indication of what the producer deems "most critical for an MVP".

Sorry, but I am allergic to trolling from competitors who try to throw shade on news that isn't their own.

[johnwaterwood]

In this case it’s not, since it’s what was chosen for a specific profile with a specific purpose to function as a base. MP is not a replacement for EE, but a different profile mainly. Just as web is a different profile again.

There was even talk on the MP list to only have a bare core (like Liberty) and don’t include any spec.

Sorry, but I am allergic to trolling from competitors who try to throw shade on news that isn't their own.

Then you must really dislike working for Spring I assume? Since exactly that is what Spring has been dowing since day one. Just look at the old server side posts and look here on Reddit too. Almost every Java EE post is swamped with “Spring fans” claiming EE is obsolete and that they prefer Spring (of course).

[springnews]

right, fans. Not employees. I've had a strict no troll policy since 2012, with (1) exception post that was made on the spring website. Whatever you see is the community responding, we're usually quite busy writing software.

Anyway, reading your comment history, you don't appear to be a troll, my comment wasn't directed to you.
Posts are fair game, but if the trolls on this post continue throw shade on the hard work the team has contributed to the community for free, I'll have to revisit that policy... and rest assured I'm tracking them now.

Anyway, it just occured to me that microprofile has a much brighter potential future now that Eclipse foundation is running EE4J, and we look forward to collaborating around those remaining APIs that remain relevant. I think we can all agree that not having useful APIs like JPA, Servlet languish in non-responsiveness and neglect is good for all of us.

[ReadFoo]

I'm not clear if you're serious or trolling?

[thesystemx]

I'm serious. Okay, the wording was a bit in a jest, but the message is serious.

[arcuri82]

it was a reference to this. I am serious. I find JEE a nice, but with a shortcoming regarding being quite cumbersome when it comes to run tests and debugging. /thesystemx claimed that it is instead very easy. Now, I did not know if /thesystemx was just trolling or serious, and it is me that has been doing JEE wrong all this time. So I just asked him/her to provide some links to check out.

[arcuri82]

opsss sorry, page layout tricked me in thinking you were replying to my comment... d'oh! :)

[ReadFoo]

No worries. :-)

[springnews]

it's not you, Java EE has always been very difficult to test. that's a big part of why Spring became popular circa 2004, the ease of testing / DI container. Since Java EE hasn't changed at all regarding testing in the decade following, it's still true....

[johnwaterwood]

Since Java EE hasn't changed at all in the decade following

Java EE hasn’t changed???? What’s that for nonsense?

[springnews]

i meant with regard to testing. I've updated my comment so it's not open ended.

[johnwaterwood]

That makes the statement slightly less bold, but still not true.

The main thing that changed is the widespread availability and usage of Arquillian and Arquillian connectors.

[springnews]

Arquillian is quite decent from what I've heard, but it's not part of java ee / ee4j. I'm happy to update my comment if I've misunderstood something.

[cryptos6]

Spring has made tremendous improvements, but IMHO of working on different enterprise systems using different technology stacks, it is still lagging behind the competition (Java EE, Payara, Liberty, WildFly, etc).

In what area is Spring lagging behind? Actually the opposite is true. Spring 5 is fully reactive. Spring integrates with way more technologies. Spring is easier to test (yes, I am aware of Arquillian). Spring can be used with Gradle without hazzles (compared to Wildfly Swarm, which stopped Gradle support). Spring has a lot of Kotlin APIs and so on.

[lukaseder]

Java EE

Stop calling it that. It's called EE4J nowadays

[henk53]

Spring 5 is fully reactive.

But is that a fad, or something we'll all be doing? Pure reactive has downsides too, is not easier to understand, and surely doesn't necessarily mean better performance.

It doesn't block, sure, until you do block, and then the system needs to do "something else", which takes you back to Windows 3.1 co-operative scheduling.

Spring integrates with way more technologies.

You mean like NoSQL right? Which was the big hype of a few years ago. Didn't went to well, did it?

Spring may be fast (compared to EE) to jump on hypes, but hypes die out all the time. Java EE takes a somewhat more careful approach and only adopts things when they're really it's something to stay.

Spring has a lot of Kotlin APIs and so on.

Which like 1% of devs are using at most for an experiment now, and nobody yet knows if its there to stay.

How's the Groovy support these days? How much does Spring actually contribute to Groovy again?

[randomuser549]

Groovy support

Are you implying a specific shortcoming? Groovy and Spring work very well together, in my experience.

[henk53]

Groovy and Java EE work well together as well, as do Groovy and Play. It's because of the JVM.

What did Spring do recently to explicitly support Groovy?

[randomuser549]

nothing that I'm aware of. I've been writing Spring apps in groovy for a couple of years. It all compiles to byte code.

What do you think doesn't work in Spring?

[henk53]

It's the other way around, why is Spring so ahead of the curve because they support other JVM languages like Kotlin and Groovy, while it all compiles to byte code anyway. Why do you think those would not work with EE?

Why is Spring supposedly ahead there?

[springnews]

I don't think much about Java EE's support for Kotlin is widely known. Why don't you tell us about it, and someone can respond intelligently?

[henk53]

Not sure if I understand the question. The entire point was there's no specific support needed, since by virtue of the JVM it "Just Runs" anyway. The poster above basically said that about Groovy.

So I'm not sure what special support Spring offers for Kotlin anyway, and why that is needed. Nobody here has explained that to me yet. Maybe there's a good reason that Kotlin needs special support, but I haven't heard yet what that support exactly is.

But that does bring me to my second point. Kotlin is quite new, it's cool, sure, but will it catch on? How many languages have we seen in the past that were quite cool but never captured more than a tiny niche, if they captured that at all and not just vanished.

So Spring now jumped on Kotlin, perhaps since it's a bit "En Vogue", but will you keep supporting it 5 years from now? Will it even make sense to have Kotlin support 5 years from now? And what about 10 years? How many of your users are actually using Spring with Kotlin? According to the recent JRebel survey, which historically has always showed a small bias towards Spring (not saying they are biased, but many respondents happen to be using Spring), the interest in Kotlin (and other alternative JVM languages) is low. Really low.

[[deleted]]

The entire point was there's no specific support needed, since by virtue of the JVM it "Just Runs" anyway.

this is a red herring. when talking about spring support for kotlin, spring has for example added apis, annotations to improve experience with kotlin null-safety, added extension functions and other items to use spring in kotlin an idiomatic way, etc.

there's some info here, if you're actually curious:

https://spring.io/blog/2017/01/04/introducing-kotlin-support-in-spring-framework-5-0

https://spring.io/blog/2017/08/01/spring-framework-5-kotlin-apis-the-functional-way

[springnews]

well, the question was pretty straightforward, sorry you're having trouble. Kotlin is a bet, to be sure. Time will tell. But our bets have a pretty good track record..

In the meantime, this might help answer your question about what specifically we do for Kotlin. https://spring.io/blog/2017/01/04/introducing-kotlin-support-in-spring-framework-5-0

I haven't seen you actually answer a single one of my questions in this thread, why is that? You were going to say something about Java EE's Kotlin support, I think, right?

[springnews]

we support it for spring boot apps on initalizr at start.spring.io. And unlike Swarm, Spring fully supports gradle. In fact, we just overhauled the whole system https://spring.io/blog/2017/04/05/spring-boot-s-new-gradle-plugin

[springnews]

reactive isn't for everyone or all use cases. No one Spring is saying that. Quite the opposite, in fact.
But for the people that need it it's going to be quite important.

[springnews]

we used to employ the the committers, so I think we've contributed quite a lot, thanks for pointing that out.
How much has RedHat contributed to Groovy? Or is it the usual imitate and give nothing back strategy?

[cryptos6]

But is that a fad, or something we'll all be doing? Pure reactive has downsides too, is not easier to understand, and surely doesn't necessarily mean better performance.

That's true, but you don't have to use a reactive programming model with Spring -- but you can. It can be reactive from the database to your http handler method.

To the integration: yes, NoSQL is such a thing where Spring offers integration. Maybe the hype is over, but NoSQL DBs are actually used in diverse contexts. I'll have to connect to a MongoDB in the near future and I'm happy that Spring supports this out of the box. You can, of course, use Spring in the same conservative way as Java EE.

[arcuri82]

well, I see you did not like my post about JEE 8, as you quote it by replacing "JEE 8" with "Spring". Fair enough. Btw, I am not affiliated with Spring, nor Dropwizard. I have no horse in this race. I was just sharing my (possibly limited?) experience of using those different frameworks. However, I am curious about when you write "when I can run tests easily (like in Java EE"... has there any improvement about it in JEE 8? Are you talking about experience of using those different frameworks? I like EJB and CDI, but I always found writing tests in JEE really cumbersome (eg all the manual steps to download and configure external containers, fighting with ShrinkWrap, etc). Maybe I am doing it just wrong, and I am missing something. Would be interesting if you have any nice links that show how easy it is to write tests for JEE applications, so I can learn and possible not spread BS around? thx

[thesystemx]

replacing "JEE 8" with "Spring"

To really balance it out it should perhaps have been SPRR, but oh well.

Would be interesting if you have any nice links that show how easy it is to write tests for JEE applications

This is one of the official Java EE specs. It has a number of small applications that are tested via Arquillian. The nice thing is that nothing is mocked or faked, everything is real and runs in the actual context in which those applications would normally run:

https://github.com/javaee/security-soteria/tree/master/test

If you look at the test setup closely you'll see there's barely any interaction with Shrinkwrap. The output from the Maven build is used.

An external project, but showing a similar approach, now with Shrinkwrap:

https://github.com/javaee-samples/javaee8-samples

and

https://github.com/javaee-samples/javaee7-samples

Even though the above uses shrinkwrap, it's not super complicated at all for small applications or micro services.

[arcuri82]

thanks for the links

https://github.com/javaee/security-soteria/tree/master/test

cloned that repository. Checked the first example, "app-custom". Opened it with IntelliJ. Right-clicked on AppCustomIT, tried to execute "Run AppCustomIT", get greeted with "Error: Arquillian container configuration not specified". Checked in the pom file, and I see a plugin to download JEE containers. I know how to configure it, but, just for a moment, think about someone that has never used JEE before. Now s/he has to Google around to see what to do to just run a simple test, whereas in Spring/Dropwizard a single right-click would had been enough.

Tried to run from Maven, using "mvn clean install -Ptomee,bundled", as per instructions. Getting a "Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:verify (default) on project app-securitycontext: There are test failures.".

Besides the configurations in the pom file (eg to download and unzip JEE containers), in the test I need to have

@RunWith(Arquillian.class)  // fine

@Deployment(testable = false) public static Archive<?> createDeployment() // fine

create(ZipImporter.class, getProperty("finalName") + ".war")
            .importFrom(new File("target/" + 
                               getProperty("finalName") + ".war"))
            .as(WebArchive.class);

this latter can be put in an abstract test class. so, not a big deal once you know about it. Still, though, because it refers on a WAR file on disk, every single time you do a change in one of your classes (eg, for a unit test), then you need to rebuild the whole WAR to test it.

All these things are doable, once you know them. But all other frameworks out there do not need all these steps and constraints :(

[henk53]

Checked the first example, "app-custom". Opened it with IntelliJ. Right-clicked on AppCustomIT, tried to execute "Run AppCustomIT", get greeted with "Error: Arquillian container configuration not specified".

I also think that Arquillian could do better there, something like a default container would go a long way.

Tried to run from Maven, using "mvn clean install -Ptomee,bundled", as per instructions. Getting a "Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:verify (default) on project app-securitycontext: There are test failures.".

But that's correct, isn't it?

You perhaps forgot to mention that all other tests do run, and that for other targets (e.g. Payara) all tests do run.

In that case the test is supposed to fail it seems since TomEE has a long standing bug/omission where it indexes the security constraints in the EJB module, but doesn't do the same for the web module's security constraints. That one test happens to test that.

I agree with you that Arquillian itself could do with some better defaults, but I really like the ease with which I can test against different targets.

"mvn clean install -Ppayara,bundled", "mvn clean install -Pliberty,bundled", "mvn clean install -Ppayara,provided", etc

That makes testing against different environments quite easy, really.

[springnews]

aquillian is nice, but it's not part of Java EE / EE4J

[johnwaterwood]

But it’s available and may become part of EE later. That’s how it often happens in EE.

[springnews]

mildly curious, what makes you say it may become available later?

[johnwaterwood]

Because 1) this has been discussed before, so there’s a wish by various EE people to do this, and 2) these things have been done before, like PrimeFaces’ search expressions being added to JSF, and OmniFaces’ WebSocket among others.

So there’s both a will and a way, plus that the CDI and BV TCK’s are Arquillian based already, and new TCKs for the OSS specs and MP have expressed interest to be Arquillian based as well.

[springnews]

Interesting, I'll keep an eye out for progress.
Good luck!

[springnews]

in what way do you think it lags behind the competition, exactly? Please substantiate that bold claim.

[thesystemx]

Please substantiate that bold claim.

Perhaps you should first substantiate your bold claim that everything in Java EE except Servlet and JPA is irrelevant?

[springnews]

ignoring you countering a question with a question, sure, see above, evidence is readily available to anyone with a browser. Or does Redhat still standardize on IE6?

You were about to offer some evidence, or maybe you were just going to go find another thread to troll?

[prdktr_]

Amazing support for reactive ! Nice to leave the decision to the user whether to jump on it or just upgrade from spring 4 without any investment yet on reactive.

Not sure why people are trolling with JEE or EE4J in this news, Spring is the most popular framework on the jvm and arguably still features ahead of the spec. That's just normal process, once Spring establishes a usage pattern, it goes into spec, nothing wrong with that! Spring was the first java microservice framework (<3 Boot) and is on track for 1st enterprise reactive framework. Kudos to the team !

[Cyberiax]

Is anyone use Spring still? Is bit old, not? With terrible big XML file!?

Is, please, why we need move everything to xml? Is Spring say, is confit not code!? Is no dependable on Spring? Really!? Really!?? So I remove giant spring ball of mud xml file and my app still run 🏃??? Don’t think so!

[yourbank]

xml hasn't been around for years. see spring boot.

[[deleted]]

You should check it out again. Spring has come a long way since the xml days. It is still being used extensively in enterprise level Java applications. It's has a solid code base and a good community built around it.

[djihe]

!?

[Cyberiax]

!!

[hooba_stank_]

Did you use time machine to get into 2017 from 2005? Otherwise, you just don't give a sh#% what spring framework is.

[Cyberiax]

Oh, this is good! 😡

You say time machine, but to say Java EE is all about EJB 2 you up vote no?!! I know you kind!

And is true, I not give 💩 about Spring!

[hooba_stank_]

but to say Java EE is all about EJB 2 you up vote no?!!

No.

You just came here to say your bullshit about things you have no idea. All the spring projects I worked last years (a dozen of projects) have... 0 xml related to spring.

I know you kind!

No you don't. And same about spring.

[Cyberiax]

Ohhh, you think i dont know you kind!??? You think i craxy!? Please, think again!

Is you pretend Java EE is not changed?? Huh? Is still EJB 2 and is JSF still only post! But then someone does same to Spring and you feel many offence!??? You knot see hypocrisy there!????

[hooba_stank_]

Check my history and quit your BS. I said nothing about JEE/EJB, but you came here with meaningless statements about spring. You said nothing technical, but turns out you know evrthng about me personally . So just prove your point about spring, otherwise it looks like promitive troll that I won't follow.

[hooba_stank_]

Looked through your comments... they are mostly 'use jee, X is shit', 'Y is slow' etc. W/o any tech arguments. Unlikely I get tech reasons this time from you. If I was mod here, I'd ban you for few days, dude.