Sorting a list of employees by salary in java:
List<Employees> someEmployees = getEmployees();
//make a copy, so we don't mutate the original list
List<Employees> sortedEmployees = new ArrayList<Employees>(someEmployees);
Collections.sort( sortedEmployees, new Comparator<Employee>(){
public int compare( Employee e1, Employee e2 ) {
return e1.getSalary().compareTo( e2.getSalary() );
}
});
Yikes.
In GScript:
var sortedEmployees = getEmployees().sortBy( \ e -> e.Salary )
All statically typed and verified, supporting full code-completion. Closures and type-inference sure clean code up, don’t they?
Filed under: Development, GScript | Tagged: gscript, java
Cool, I wonder if it’s possible to use closure (apache collections) and function (google collections) to achieve a 1-liner as well.
Not really. In java you are tied to the clunky anonymous class syntax which pretty much requires at least three lines of code, and five if you aren’t jamming it all together. Plus in java you have to annotate all the types which further junks up the code.
With closures and type-inference, we can boil the operation down to its essence. What do we want to do? Sort this list by something. What is that something? The employees salary.
It doesn’t get much leaner than that.
Hello Carson,
I showed this page to one of our developers. He wonders what that means?
this peace: “\ e -> e.Salary”
Thank you,
Stanislav.
That’s what we call a block, which is basically a closure. You can also think of it as a tiny anonymous function. In the case of the sortBy() method, it takes a block that takes one element of the list as its argument and returns some Comparable value as a result, and the List will be sorted based on those values. So the code above sorts the list of employees based on their salaries.
The part after the \ but before the -> declares the parameters; in this case, there’s a single parameter named “e”. The part after the -> is the value of the block; in this case, it evaluates to the Salary property of the employee argument. Most blocks are one-liners like that, though you are allowed to have multiple statements (in which case you have to enclose them all in { } and use a return statement).
You don’t see any type declarations because type inference does the work for us; we know that the sortBy() method on a List takes a block that takes a parameter of type T and returns a Comparable, so calling sortBy() on a List means that e has to be an Employee.
Blocks are a new feature of gscript that’s available in our latest set of releases (ClaimCenter 5.0, PolicyCenter 2.5, and BillingCenter 2.0), and they dramatically simplify a lot of boilerplate Java code where you constantly have to loop over things or define anonymous inner classes, and we think they make the code much easier both to read and to write.
Alan,
Thanks for the reply. Unfortunately, we are stuck with 4.0.4 for a long time.
Stas.
Stanislav,
If you show your business users the ClaimCenter 5.0 interface, they may force you to upgrade! It’s a much better looking application.
Cheers,
Carson
CC 4.0.4 was good, but CC 5.0 introduces some key features, such as archiving, support for Java 1.5, an updated UI, and a configuration environment that will shorten project times.
We are very excited about the release, and we hope your business users will want the features so much that you’ll get to start the upgrade soon.
[...] A List Posted on May 19, 2008 by Carson Gross My first post showing some GScript on this blog compared sorting in Java with sorting in GScript. Today I [...]
I have a couple of questions about GScript.
1 – are there automated static analysis tools available for GScript? One of the nice things about Java is the level of tooling available (eg CheckStyle and PMD are two excellent examples of this). Does GScript development have the same access to automated static analysis tools?
2 – what about GScript and code coverage tools? For example can EMMA and Cobertura be used against GScript as easily as they are against pure Java?
Richard,
There certainly aren’t the tools available for GScript that are available for Java. Right now GScript compiles to an in-memory runtime representation of the parse trees and, thus, doesn’t currently work well with existing tools. In the next major release Alan Keefer has inspired us to go all the way down to byte code with GScript, which will make it play much better with java-based tools (e.g. JProfiler, a personal favorite.)
GScript currently doesn’t produce any compilation artifacts (i.e. class files) Rather everything is lazily compiled as necessary. I prefer this scripting-language-like mode of development, but it might make integrating with java-based tools that work with .class files a bit trickier. We’ll likely give the option of producing .class files in the next release, which will help. However, tools that rely on parsing java syntax will obviously not work.
Although this isn’t as positive an answer as I’d like to give, there is one piece of good news: the GScript parser will be included with the language, as will tools we use internally for upgrading/analyzing our code, and we are hoping that new tools will spring up around them.
Cheers,
Carson
Hi Carson,
I’d like to know more about the inner-workings of GScript – there is not a lot of information online…
Do you use custom class loaders to load scripts into classes? If I use a profiler (even verbose:class) on my JVM will I see all these classes being loaded? Do you use any kind of outside process, or is all code ran in the JVM? Do you instrument existing Java classes that interact with GScript? Do you override or replace regular Java classes that interact with GScript?
Thanks,
Asaf.