• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

"Spring for Scala"?

 
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
chris webster
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
  •  
    Author
    Posts: 15
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 2407
    36
    Scala Python Oracle Postgres Database Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 15
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Sheriff
    Posts: 67746
    173
    Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 15
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Sheriff
    Posts: 67746
    173
    Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic