aspose file tools*
The moose likes Scala and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Languages » Scala
Bookmark ""Spring for Scala"?" Watch ""Spring for Scala"?" New topic
Author

"Spring for Scala"?

chris webster
Bartender

Joined: Mar 01, 2009
Posts: 1479
    
  11

A lot of people noticed that Spring creator Rod Johnson joined Typesafe a few months ago. Does this imply Typesafe is looking to build Spring-style "enterprise" frameworks for Scala? And to what extent would such frameworks be constrained by compatibility with JEE platforms? For example, my very brief exposure to the Scala web frameworks Lift and Play gave me the impression that Play felt more developer-friendly as it avoids a lot of the JEE cruft, but it does not allow you to deploy your app to a JEE servlet container, which many people feel is a disadvantage.

So should Scala frameworks be aiming for JEE compatibility or to offer a better alternative to JEE?


No more Blub for me, thank you, Vicar.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60077
    
  65

The inability to deploy to JEE container such as Tomcat is what has kept a number of my project on Play version 1. I don't need to use JEE in the project, but I do need to be able to deploy to Tomcat.

The prevailing attitude seems to be" "That's old fashioned", or "Time to move on".

Well, that doesn't cut the mustard. The guy cutting the checks is invested in the Tomcat infrastructure and has many more apps deployed that just the ones I'm working on. He's not gonna suddenly upend the apple cart and switch to heroku or some such just because of a framework choice for a couple of apps.

I find the "onward at any price" attitude very off-putting.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
chris webster
Bartender

Joined: Mar 01, 2009
Posts: 1479
    
  11

Excellent points, Bear, but regardless of the Scala question, I wonder just how we would ever be able to move on from JEE even if a better alternative does come along? As you say, there is a vast amount of current investment in JEE (probably far more than there was in earlier technologies when JEE came on the scene), nobody wants to re-write their existing systems if they can help it, and new applications need to fit into that infrastructure, so it seems we are likely to be constrained by backward compatibility with JEE for decades to come, regardless of the alternatives.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60077
    
  65

True. The projects I'm referring to are not JEE projects. To be honest, except for JSP templates, I didn't miss JEE much while working on those projects. (The Groovy templates in Play 1 are cool in their own right, but there were a lot of JSP-isms that I missed.)

So I think that there is room for something other than JEE.

My beef is with deployment to JEE containers, rather than actually using JEE when coding.

The things that I think Play does better than raw JEE that made me go with Play in the first place:
  • Ease of routing URLs to controllers, and the automatic parameter binding
  • API for calling web services
  • Really smooth JPA integration
  • Josh Suereth
    Author
    Greenhorn

    Joined: Jan 24, 2013
    Posts: 15
    I don't think Typesafe is aiming to release something quite so heavyweight as either Spring or JEE. If you look at our offerings, you'll see that Play is a webframework designed to get out of the way of other technologies, like front-end JS frameworks, or back-end server processes. Akka is similar in that, for the domain it solves, it does it very well, but can still interact with existing services.

    I gave a talk at Spring One this year about leveraging akka *with* spring, embedded in a way that you could take advantage of both "frameworks".

    For the most part, The Typesafe 'stack' aims to be a loosely coupled affiliation of well-maintained libraries that cover as many aspects of development as we can. Akka focuses on concurrency, Play focuses on moving data around in HTTP servers, and SLICK focuses on getting data into and out of RDBMS or NoSQL stores.

    Really, the goal is to be a lightweight stack. For Example, Play comes with "anorm" out of the box, but it's quite easy to insert your own ORM.

    Rather than issue "Standards", ala JEE, or require a full on container, ala Spring, the Typesafe stack aims to be a set of building blocks, with a default foundation you can use, or toss out, depending on your needs.


    Hope that helps!
    - Josh
    chris webster
    Bartender

    Joined: Mar 01, 2009
    Posts: 1479
        
      11

    Thank, Josh. I can see the value in this lightweight and flexible approach, but isn't that also liable to restrict Scala's penetration of the "enterprise", given the compatibility issues that Bear pointed out?
    Josh Suereth
    Author
    Greenhorn

    Joined: Jan 24, 2013
    Posts: 15
    I'm not certain it'll block *scala* adoption. My first production app with Scala was a JEE JBoss application where we started using Scala (and the loan pattern) to handle some tricky transaction atniques with JMS messages.

    You are correct that Play not running as a WAR means you can't deploy it to a traditional app server. However, I think in this case the benefit is definitely worth it. It's taken the JEE specs a while to cope with emerging technologies and evolving hardware, while Play was able to pick up the best-of-bred HTTP JVM server technology (Netty) and directly use it. While some web servers were supporting alternative APIs (like Jetty), it was a long time before all the rest of the containers caught up. Forcing users to use Jetty to take advantage of features isn't much different from just using *one* hosting technology and given that your full effort.

    So yeah, I understand there's a lot of tools and such out their for WARs. You can still use Scala with JEE technology. Play itself decided to go a more opinionated route. My opinion, is that Java itself may be moving this direction as well. At least, the things I saw in the Jigsaw branch lead me to believe "standalone java application" will become a far more conventional, and easy to manage, deployment option. Granted, we're taking far down the road, but Play! is a forward thinking web-application framework.

    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60077
        
      65

    Two thoughts:

    Josh Suereth wrote:but Play! is a forward thinking web-application framework.

    I agree. Perhaps too much so. Or perhaps not. They're locking themselves out from a lot of existing enterprises that aren't going to change their deployment strategies anytime soon. And even small guys -- like the one I'm doing some work for -- that don't have a dedicated IT staff, aren't going to risk moving off something that they know works and is up and running. If I tried to get him to adopt heroku or something similar, he'd think I'd gone crazy.

    But that balances with new and upcoming companies that are looking to use the latest bleeding edge stuff. It remains to be seen how all that will shake out.

    Josh Suereth wrote:I'm not certain it'll block *scala* adoption.

    But Scala adoption is, in my opinion, most definitely tied to the "killer app" that's going to make people want to use it. It's not going to go much of anywhere just because developers think it's cool. Given the relatively minor foothold that Play has attained, and the general dissatisfaction I hear with Lift, it doesn't exist yet.

    I hear a lot of "Scala is the next Java" from a lot of its fans, but few that I know are actually using it for anything but play-ware (small 'p').

    What, in your mind, is the compelling use case that's going to make corporate decision-makers allow Scala into the enterprise (big or small)? The enthusiasm of the developers for the language isn't going to count for much in any company except the very small or startup where developers are calling the shots. And those are not the companies that will wag the dog.
    Josh Suereth
    Author
    Greenhorn

    Joined: Jan 24, 2013
    Posts: 15
    Bear Bibeault wrote:Two thoughts:
    They're locking themselves out from a lot of existing enterprises that aren't going to change their deployment strategies anytime soon. And even small guys -- like the one I'm doing some work for -- that don't have a dedicated IT staff, aren't going to risk moving off something that they know works and is up and running. If I tried to get him to adopt heroku or something similar, he'd think I'd gone crazy.

    But that balances with new and upcoming companies that are looking to use the latest bleeding edge stuff. It remains to be seen how all that will shake out.


    That's the case with a lot of "cutting edge" software. Eventually if young hip new projects keep picking it up, it'll be the older safer technology in a few years. Yes, some enterprises aren't going to pick it up immediately, but some enterprises are still successful using COBOL. Different organizations have different needs, and Play is targeting a different market for now.

    IIRC, someone has adapted play to work within WARs and JEE. I think you could definitely have such a thing, but most likely if you're the same organization that is unwilling to move from JEE containers, you may also have issues moving frameworks. I think these kinds of backports are probably a better way to go for larger adoption than to veer the central core of the framework.

    The practical bit, is we're seeing clients pick up and use Play *beside* their JEE applications, even large more conservative organizations. Perhaps the path to success is longer, but hopefully the *life* of the framework is also longer because it's forward thinking.

    Bear Bibeault wrote:
    Josh Suereth wrote:I'm not certain it'll block *scala* adoption.

    But Scala adoption is, in my opinion, most definitely tied to the "killer app" that's going to make people want to use it. It's not going to go much of anywhere just because developers think it's cool. Given the relatively minor foothold that Play has attained, and the general dissatisfaction I hear with Lift, it doesn't exist yet.

    I hear a lot of "Scala is the next Java" from a lot of its fans, but few that I know are actually using it for anything but play-ware (small 'p').

    What, in your mind, is the compelling use case that's going to make corporate decision-makers allow Scala into the enterprise (big or small)? The enthusiasm of the developers for the language isn't going to count for much in any company except the very small or startup where developers are calling the shots. And those are not the companies that will wag the dog.


    I think we may be able to agree to disagree here. I don't see Scala as requiring a killer app. It's powerful enough to compelling *on its own*. Play migrated to an all scala-backend *from* a java/scala backend. Why? Because of the language. Akka is implemented in Scala *because* of the language (although is supports a Java API).

    SO here are what I see Scala's killer features *for corporate decision makers*

    1. Reduced code size in general. Helps limit the number of bugs just by virtual of having less code (statistical correlation)
    2. Improves the development code speed of the "top-tier" programmers (circumstantial evidence)
    3. "lower-tier" programmers code abilities/speed *appears* unaffected (circumstantial evidence)
    4. Multi-core program is easier in Scala, not because Java can't handle it, but because Scala embraces patterns and defaults that work well with lots of threads. Its libraries take a similar approach. So, while Scala's future's APi can be used in Java, it's far more elegant (and harder to screw up) in Scala. This means on *average* using Scala and its paradigms should help leverage more power from your machines.
    5. Type safety. Unlike dynamically-typed languages, Scala can help a large team maintain a code-bases (refactor safely, etc.) and write less testing code for similar levels of coverage. This means better working code with less effort. It also means, IDEs can be far more helpful.

    Basically, Scala helps improve developer speed, reduce codes (through reduced code size) and push developers towards multi-core friendly paradigms (taking better advantage of hardware).


    In terms of the killer *language* features for *developers* (more concrete) -> In order of how important I find them on a daily basis.

    1. expression oriented/typeinferred syntax. Everything returns something. The compiler attempts to figure out what, if it can.
    2. Pattern matching (A lot of languages fail to have this, and it's be far the most used language feature for me on daily code)
    3. Closures (This is less compelling as other languages add them, however the way they exist in Scala is fairly elegant and simple to understand).
    4. Collections library. Scala's standard collection library is *WAY* better than any other language I've used in terms of being productive and getting info out of data. Once you learn it, you wont' want to use another.
    5. Implicits. Scala's implicit system allows you take the "edge" off an API by allowing defaults to be specified once within a scope and not again until configuration is necessary.
    6. traits. Scala allows a limited form of mutliple inheritance, that among some surprising things, allows an encoding of virtual/extension classes that works well with FP code. See "cake" pattern as used by Precog.
    7. type system - Scala's type system is more advanced than a lot of other languages. It features the union of some really-tough-to-join ideas. In certain tricky situations, Scala can express some nice behavior that would be rather ugly in "more popular" statically typed languages (like C#/Java).



    Of course, this is my opinion and some of the points are "circumstantial" in my experience. Would love to hear your thoughts.

    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60077
        
      65

    Josh Suereth wrote:SO here are what I see Scala's killer features *for corporate decision makers*

    Perhaps I am jaded from 35 years of butting heads with the "corporate decision makers" (in fact, I hope that I am and that a sea change is coming in which the developers actually get asked for their opinions on what will make them most productive), but I don't see 1, 4 and 5 meaning a rat's pattootie to these people. Just not on their radar, and trying to explain it to them will result in a lot of nodding heads, but no action. Items 2 and 3 could be somewhat compelling if, and only if, there are high-level influential developers who can evangelize the heck out of making a change. I've been in that position a few times, but only a few times in a career spanning over three decades.

    Maybe things are changing. One can always hope.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: "Spring for Scala"?
     
    Similar Threads
    Routes into Scala?
    a decade of "keep the code out of the jsp"
    Is Lift a Scala framework like Play?
    Anyone using the Play framework
    Springtime for Scala?