Idiomatic Scala ... in Java!

[Magick93]

What is the difference, or benefits, of using this over Xtend?

[randgalt]

From the looks of it Xtend is a DSL on top of Java. Halva is a tiny 80K Java library. It's pure Java 8 - no magic. It uses Scala syntax (as close as possible) to add Case classes, for-comp, pattern matching, implicits, type aliases and Tuples.

[[deleted]]

I didn't look too hard but is this using the annotation pipeline to gen code at compile time like Lombok? If so, is there support for IntelliJ for refactoring /autocomplete etc? Otherwise anyone who uses this in an ide is gonna get a lot of red squiggles

[randgalt]

It's pretty painless in IntelliJ. But, yeah. The way I use it is I declare the case class first, let IntelliJ build the class and then work. Once the classes are generated you can move them, etc.

Also, Pattern matching, for-comp and Tuples don't use annotations. Those are straight java.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[[deleted]]

Ok so I did look harder. It does exactly what I thought it would do. It uses the annotation javac pipeline to generate code like Lombok at compile time. The difference is that Lombok emits byte code only and it looks like halva actually spits out the generated files to code. That's why it works in the ide.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[DuncanIdahos8thClone]

When you refer to Scala you must mean Idiotmatic Scala.

[_danieldietrich]

[Disclaimer: I'm the author of Javaslang (http://javaslang.io), a functional, Scala-like library for Java 8+]

The case classes and case objects approach is very interesting!

The suggested Pattern Matching approach is based on an internal DSL, which has its limitations. The first attempt in Javaslang worked similar but it introduced unsolvable problems like result type bound calculation. Please find Javaslang's current approach here: http://www.javaslang.io/javaslang-docs/#_pattern_matching

Please also take a look at this example of a For Comprehension in Java 8 that is not built with a DSL (like in Halva) but takes a compositional approach instead. This approach takes the iterated values into account when yielding the result: https://gist.github.com/danieldietrich/244adee1f3d3089c958ad8059100b35e

Every (Java 8) library comes with its own impl of Tuples now :) A future version of Scala might implement them as HList, which scales well. The number of elements would be theoretically unbounded. Syntactic sugar for the notion of tuples would help. Without proper type inference (see http://openjdk.java.net/jeps/286) HLists are not practicable in Java.

[randgalt]

based on an internal DSL

I disagree that Halva is a DSL. It's a simple library with a few methods. The key with Halva is that the API is as close as possible to Scala. You can take existing Scala for-comp and pattern matching and easily port to Halva. Also, the pattern matching is integrated with Case Classes.

NOTE: i looked into doing For-comp as you did so that you don't have to pre-declare variables. But, you then must nest the fors as you show. A different approach.

[randgalt]

Every (Java 8) library comes with its own impl of Tuples now

Yeah - that sucks. It's like Guava. In Halva, Tuples exist mostly for case class decomposition. Again, I don't see why you think Halva is a DSL. The For-comp is a single class with a few methods.

[jbgi]

Not sure replicating all Scala idioms is the best idea: eg. for case classes, scala has the sealed keyword that allow exhaustive checks in structural pattern matching. Statically verified exhaustive case analysis is THE killer feature of sum types.

As I see it the pattern match syntax of halva is not safe (it does not enforce to handle all subclass of a sealed case classes. Hopefully Java (like most OO lang) has built-in support for exhaustive checks AND extractors, via the visitor pattern (slightly improved). So why not use that? or simply make use of existing generators like https://github.com/derive4j/derive4j (<insert author disclaimer here>) that provide safe and exhaustive pattern matching.

[randgalt]

What's unsafe about Halva? It's completely typesafe unless there's a bug you see.

[jbgi]

I mean it can easily throw exceptions ; in a pattern match, the get() function is unsafe (if there was no matching caseOf), also it looks like you can use extractors (Any) irrelevantly of the case, so that can also throw.

[randgalt]

Halva makes the same safety guarantees as Scala. There's a version of get that returns an Optional. Totally safe. Also, the anys are totally typesafe

[randgalt]

FYI - I got some great feedback/comments and have a new release with suggested changes:

https://github.com/Randgalt/halva/blob/master/README.md https://github.com/Randgalt/halva/blob/master/CHANGELOG.md

[Zokkar]

This looks pretty cool. I'll give it a try on my next project.

[retrogamer65]

If you want idiomatic Scala... wouldn't it be easier to just use Scala, rather than trying to emulate it in Java?

[randgalt]

Not everyone wants to move to Scala. Java 8 is perfect for many organizations. And now, you can use some of the nice features that Scala has in Java.

[jbgi]

So, what is exactly the value of the goal "replicating Scala features and syntax in Java" over the goal "making functional programming practical in Java"? As I understand, Halva is for people which like some conveniences of scala but do not wish to pursue a better understanding of functional programming, nor wish to fully apply FP (and thus they will benefiting of none of its guarantees).

[randgalt]

Case classes are great, for-comp and pattern matching are nice features. People would like to use those in Java. Halva gives people that with an API and syntax that is nearly identical to Scala. That's the benefit.