Group items tagged

I am working on a web site that will help students practice their Scala programming skills. As I labored along, writing my JSF app code, I thought "this is silly-why not practice Scala at the same time?" But I like JSF and wasn't ready to jump to Lift or Vaadin. With Eclipse, this isn't all that hard. Install the Java plugin. Make a dynamic web project in the usual way, using the Java EE perspective. Then, switch to the Scala perspective, right-click on the project, and, if all planets are aligned correctly, you will get a menu item "Add Scala nature". (If they are not, see here for a manual approach.) Add your managed beans as Scala classes. Finally, switch back to the Java EE perspective, select the project properties, and add the Scala library JAR as a Java EE module dependency. But I like NetBeans and wasn't ready to switch to Eclipse. (Unfortunately, JSF 2 support in Eclipse is pretty minimal, the Glassfish integration is a bit flaky, and the Scala plugin has very little usable code completion.) NetBeans doesn't let me add a "Scala nature" to a web project. If I add Scala files to the project, I can edit them with the Scala editor, but they just get copied to the WAR file, without any compilation. I had one look at the Ant scripts for a Scala and a web project and decided that I wasn't going to figure out how to merge them. This blog shows how you can use Maven to make a mixed Scala/Java project in NetBeans. So I gathered up JSF and Scala pom.xml files from here and here, cut out the considerable crud from the JSF POM file that was probably meant for supporting Tomcat, and merged the results to the best of my ability-see below. You use the usual Maven directory structure, but with a src/main/scala directory instead of src/main/java:

There was a recent outburst in blogs on the topic of Groovy and how it compares to Java. Although I respect the youthfull entusiasim of Groovy and Co. working on this little exercise I'm just perplexed by the "WHY?" in this whole discussion. Let me just say again: W H Y ?!?! 1. Practically no one cares about Groovy (let alone Groovy++ strap-on) beyond Grails community. So this language just as "widely accepted" as Ruby (at least for enterprise software development) 2. If you know Java it's equally "challenging" to pick up either Groovy or Scala. Don't let anyone insult your intelligence by claiming that Scala syntax is somehow more complex than Groovy. In both languages you will need to adapt to functional thinking - and that's where you will have to spend a couple of weekends… 3. If you know Groovy - you already know 90% of Scala (different syntax and few extra features can be picked up in the evening) 4. Scala is designed by people who have proper academic background, experience and talent in the area of language design - Groovy has never been that way (and anyone who dares to look inside of Groovy runtime or history of changes in it will attest to that). NOTE: it did come out rather strong - but that's how I feel about it and after some thinking I'll leave as is. Nothing personal to anyone reading it… 5. Scala as a post-functional language is years ahead of Groovy (static typing with best-in-business type inference, highly tuned mix of imperative and functional styles, powerful and done-right generics, etc.) 6. Groovy will ALWAYS be slower than Scala or Java (latest benchmarks put even Groovy++ about 50 times slower than Java) just by its nature unless someone changes the language and rebuilds the runtime from the ground up. 7. Once we get decent integration with Eclipse, NetBeans and IDEA for Scala, the Groovy will lose its only serious advantage

"Support for mixed Scala/Java projects Thumb Support for mixed Scala/Java projects and any combination of Scala/Java project dependencies, allowing straightforward references from Scala to Java and vice versa. Editing Thumb A Scala editor with syntax highlighting, code completion, inferred type hovers, hyperlinking to definitions, error markers and more. Debugging Thumb Incremental compilation, application launching with integrated debugger, hyperlinking from stacktraces to Scala source, interactive console. Navigation Thumb Project and source navigation including Scala support in the Package explorer view with embedded outline, outline view, quick outline, open type, open type hierarchy."

"I've had an opportunity recently to work on a product that needed an RIA web interface, and I chose my recent favorite tool for this, Vaadin. The services for this project needed to be highly scalable, and lent themselves well to functional techniques, so I selected Scala as my language of choice. I build my projects with Maven, for reasons I won't go into right now, and I do much of my JVM-language work in Intellij's excellent IDEA IDE. Given these tools, I found a way to facilitate very rapid development of web UI's, and I thought I'd pass it along. Another technique I use, which I'll expound on later, is creating "dummy" implementations of all of my backing services for my application. The "real" implementations are written as OSGi services, in separate modules from my UI. The UI is packaged as a war, but is also OSGi aware, with a bundle activator. This activator only gets called if the war is deployed into an OSGi container, and not otherwise. This allows the app to select which implementation of the services it uses - the "dummy" ones when it's deployed outside of OSGi, and the "real" ones when they're available. This means I can use the handy Maven jetty plugin to quickly spin up my application and test it on my local workstation, without needing all of the dependencies (like a data store and such) of my real services. That's good, in that I can get my "cycle time" down to a few seconds, where "cycle time" is the time between making a change and actually being able to test it in my browser. We can do better, though. I'm using Scala as my language of choice for building the UI as well, as it works just fine with Vaadin (and with everything else in the JVM ecosystem, for that matter, which is why I didn't choose a non-JVM language - but that's yet another rant). I compile my Scala with the Maven scala plugin - here's where the next handy bit comes into play. Turns out the Scala plugin has a goal cal

Last weekend while pondering the question "Is Scala ready for the enterprise?" I decided to write a simple Java EE 6 app entirely in Scala, without using any Java. I had three main reasons for doing this: one was just to see how easy/difficult it would be to write everything in Scala (it was easy).  Another was to document the process for others journeying down the same road (the entire project is on github).  Finally, I wanted to identify advantages of using Scala instead of Java that are specific to Java EE apps (I found several). Background The specific app I created was an adaptation of the Books example from Chapter 10 of Beginning Java™ EE 6 Platform with GlassFish™ 3. It's a simple web app that displays a list of books in a database and lets you add new books. Although it's a pretty trivial app, it does touch on several important Java EE 6 technologies: JPA 2.0, EJB 3.1 and JSF 2.0.

JSF 2.0, CDI, Scala 2.8 using Eclipse, Maven and Tomcat Tools used: * JDK 1.6 * Maven 2.2.1 * Eclipse 3.5 * Eclipse Scala plugin (I am using nightly build - http://www.scala-lang.org/scala-eclipse-plugin-nightly) * m2eclipse plugin Download the source from here

"Scalaz is a library written in the Scala Programming Language. The intention of Scalaz is to include general functions that are not currently available in the core Scala API. The scalaz-core module depends only on the core Scala API and the core Java 2 Standard Edition API. Scalaz is released under a BSD open source licence making it compatible with the licence of the Scala project. Scalaz 6.0.1 was released in June 2011, targeting Scala 2.8.1 and 2.9.0.1. "

A few weeks back, I wrote a blog entry lamenting the attitude toward IDEs in the Scala community. A few people told me that the tooling situation was better than I'd implied, so I thought I'd spend a bit of time looking at using Scala (and Lift specifically) in Eclipse. I think the situation is still a ways away from the tooling situation for Java, but it is actually quite good, and I wanted to post a quick tutorial for those interested in developing Lift in Eclipse. Prerequisites This post assumes that you already have Scala 2.8 final and Eclipse 3.6 on your system. For Eclipse, I recommend upping the Xmx setting if you haven't already - I had issues when I had multiple Lift projects imported with Xmx set to 386. Also, this tutorial is going to use Maven, not SBT. SBT may be a better build tool for Scala projects, but I'm not sure how well it works with m2eclipse - I'm going to play with that more later. I also assume you know how to install plugins into Eclipse - I will create a more in-depth screencast for doing all of this if there is enough interest.

"The past year I've been learning a lot of Scala and I'm currently working on a new project using Scala. I use LiquiBase, which is a database-independent library for tracking, managing and applying database changes. I'm also using the simple-build-tool (SBT) for my project. So I've put together a little SBT plug-in for running LiquiBase maintenance commands (update, rollback, …) from within SBT. For example, whenever I want to apply new database changes with LiquiBase I can now simply run sbt liquibase-update which sets up a new instance of LiquiBase and executes the LiquiBase update command which migrates my database to the latest version. At the moment the plug-in supports the following commands: liquibase-update, liquibase-drop, liquibase-tag, liquibase-rollback and liquibase-validate. What are the benefits of using the plug-in and not just the LiquiBase CLI? * no download/install of LiquiBase * classpath handled by SBT * no need to provide a big list of parameters or writing shell scripts The plug-in is called liquibase-sbt-plugin and you can find it here on GitHub. Feel free to use it or fork it and suggest changes. I'm still relatively new to Scala and especially SBT so any remarks are very welcome."

Last week I decided to challenge Scala's downscalability by trying to replace a Groovy script with a Scala pendant. In this article you will read about this little experiment and a comparision of the Scala result with the Groovy predecessor. But first some background about the script: Some time ago my company introduced a new spam notification system.  When it thinks that a mail contains spam, it keeps it in quarantine and once or twice a day sends an email to the recipient (me) reporting all the kept mails, together with an intranet web link for each  to release it. Here you see an example of such a mail (note: I have my mails displayed in plain text format):

Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages. It is also fully interoperable with Java

"Apache Camel is a powerful open source integration framework based on known Enterprise Integration Patterns with powerful Bean Integration. Camel lets you create the Enterprise Integration Patterns to implement routing and mediation rules in either a Java based Domain Specific Language (or Fluent API), via Spring based Xml Configuration files or via the Scala DSL. This means you get smart completion of routing rules in your IDE whether in your Java, Scala or XML editor. Apache Camel uses URIs so that it can easily work directly with any kind of Transport or messaging model such as HTTP, ActiveMQ, JMS, JBI, SCA, MINA or CXF Bus API together with working with pluggable Data Format options. Apache Camel is a small library which has minimal dependencies for easy embedding in any Java application. Apache Camel lets you work with the same API regardless which kind of Transport used, so learn the API once and you will be able to interact with all the Components that is provided out-of-the-box. Apache Camel has powerful Bean Binding and integrated seamless with popular frameworks such as Spring and Guice. Apache Camel has extensive Testing support allowing you to easily unit test your routes. Apache Camel can be used as a routing and mediation engine for the following projects: * Apache ServiceMix which is the most popular and powerful distributed open source ESB and JBI container * Apache ActiveMQ which is the most popular and powerful open source message broker * Apache CXF which is a smart web services suite (JAX-WS) * Apache MINA a networking framework"

A Scala ORM and DSL for talking with Databases with minimum verbosity and maximum type safety

In this article I'll describe the setup I use to do develop Lift applications. While more heavy-weight than if an interpreted language is used, I find this setup provides fairly decent turnaround times. So, it took a little longer than expected to write this article which continues where the previous stopped. But all good things come to he who waits The software used in the previous article all had major updates in the meantime: Scala 2.8 (2.8.1 is just around the corner) Eclipse 3.6 Scale IDE for Eclipse (though a nightly build is currently needed for Eclipse 3.6) Gradle 0.9 RC1 Lift 2.1 RC2

"sbt is a simple build tool for Scala projects that aims to do the basics well. It requires Java 1.5 or later. "

" Apache SlingTM is an innovative web framework that is intended to bring back the fun to web development. Discussions about Sling happen on our mailing lists, see the Project Information page for more info. Apache Sling in five bullets points REST based web framework Content-driven, using a JCR content repository Powered by OSGi Scripting inside, multiple languages (JSP, server-side javascript, Scala, etc.) Apache Open Source project"

"Clojure functional programming language for JVM has powerful mind-bending features. The feature that interests me the first time is its ability to "execute data as code". As demonstrated here, were I define a function process that basically executes the symbol processor with whatever params : => (defn process [& params] (eval (cons processor params))) #'user/process "

Akka is the platform for the next generation event-driven, scalable and fault-tolerant architectures on the JVM We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it's because we are using the wrong tools and the wrong level of abstraction. Akka is here to change that. Using the Actor Model together with Software Transactional Memory we raise the abstraction level and provide a better platform to build correct concurrent and scalable applications. For fault-tolerance we adopt the "Let it crash" / "Embrace failure" model which have been used with great success in the telecom industry to build applications that self-heal, systems that never stop. Actors also provides the abstraction for transparent distribution and the basis for truly scalable and fault-tolerant applications. Akka is Open Source and available under the Apache 2 License.

"Developers usually have their programs write log and debug information to the standard output during coding and testing. This results in a lot of text being printed to Eclipse's console view, often more than can be easily surveyed. Since at any given time, only a small part of this information is of primary interest to the developer, a tool which highlights specific lines or words can significantly increase the readability of this output. Grep Console allows you to define a series of regular expressions which will be tested against the console output. Each expression matching a line will affect the style of either the entire line or parts of it. For example, error messages could be set to show up with a red background, or integer values showing the state of a certain variable could be rendered in bold font. "