Lift/J getting Seven Things working as All-Java
David Pollak
As a proof of concept for Lift/J, I'd like to port the Seven Things code base to Java. Basically, this will make use of most of Lift's cooler APIs and will likely force a thinking about how to structure the APIs.
I've created a liftj branch in Seven Things where we can do the work. I've mostly gotten Boot.java updated: https://github.com/lift/seventhings/blob/liftj/src/main/java/bootstrap/liftweb/Boot.java
The first pattern I've got (and would really like feedback on this) is the "J" Java companion to Scala singletons.
For example, to access LiftRules, you use LiftRulesJ.j() and you've got all the LiftRules methods available to you.
Internally, for each singleton, I've got a Scala class named xxxJBridge (e.g., LiftRulesJBridge) with has a single method that will return the singleton.
In Java-land, I've got the J companion with the static j() method on it. I chose a method over a final static because all Lift singletons will be mockable in 2.3 (LiftRules and DB are the prime candidates, S and SHtml contain no state so they don't need to be mockable.)
What this means is:
LiftRules.addToPackages(...)
becomes:
LiftRulesJ.j().addToPackages(...)
I'm also creating Java Func0-FuncXX interfaces with a Func.lift() method that lifts the Java representations to a Scala representation. I'm also considering sitting Lift on top of Functional Java and use all the stuff that the Functional Java guys have already built (with some helper methods in either util or common that will bridge the Functional Java stuff to Scala stuff.) Any opinions on writing our own vs. using Functional Java?
So... thoughts? Feedback?
Thanks,
David
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics
localgod
Christopher Taylor
> As a proof of concept for Lift/J, I'd like to port the Seven Things
> code base to Java. Basically, this will make use of most of Lift's
> cooler APIs and will likely force a thinking about how to structure
> the APIs.
>
> I've created a liftj branch in Seven Things where we can do the work.
> I've mostly gotten Boot.java updated:
> https://github.com/lift/seventhings/blob/liftj/src/main/java/bootstrap/liftweb/Boot.java
Cool! While I must admit I'm still on the fence regarding Lift's
polyglottism, I think you're doing excellent work here :).
> The first pattern I've got (and would really like feedback on this) is
> the "J" Java companion to Scala singletons.
>
> For example, to access LiftRules, you use LiftRulesJ.j() and you've
> got all the LiftRules methods available to you.
>
> Internally, for each singleton, I've got a Scala class named
> xxxJBridge (e.g., LiftRulesJBridge) with has a single method that will
> return the singleton.
>
> In Java-land, I've got the J companion with the static j() method on
> it. I chose a method over a final static because all Lift singletons
> will be mockable in 2.3 (LiftRules and DB are the prime candidates, S
> and SHtml contain no state so they don't need to be mockable.)
>
> What this means is:
>
> LiftRules.addToPackages(...)
>
> becomes:
>
> LiftRulesJ.j().addToPackages(...)
Another alternative would be to keep the same class names but have the
Java stuff live in a different package (e.g. net.liftweb.java). We could
have similar packages for support code for other languages, such as the
JRuby stuff.
I'm not sure how Scala objects (as in "object MyObj {}", not "val foo =
MyClass()") map to Java classes, but I think the ideal solution would be
a Java class with the same name, but in its own package, with the
object's methods exposed as java static methods (though I guess that
would interfere with the mockability you mention above).
> I'm also creating Java Func0-FuncXX interfaces with a Func.lift()
> method that lifts the Java representations to a Scala representation.
> I'm also considering sitting Lift on top of Functional Java and use
> all the stuff that the Functional Java guys have already built (with
> some helper methods in either util or common that will bridge the
> Functional Java stuff to Scala stuff.) Any opinions on writing our
> own vs. using Functional Java?
from a lazyness and code/knowledge-reuse perspective, I'd prefer using
Functional Java. I think there are too many Function interfaces in
JVM-land already (essentially every JVM language that supports
first-class functions has their own implementation).
Hope that makes sense :),
--Chris
Sander Mak
>> LiftRules.addToPackages(...)
>>
>> becomes:
>>
>> LiftRulesJ.j().addToPackages(...)
>
> Another alternative would be to keep the same class names but have the Java
> stuff live in a different package (e.g. net.liftweb.java). We could have
> similar packages for support code for other languages, such as the JRuby
> stuff.
Yeah, that sounds good. Having the J suffix on classnames makes the
API feel like a second-class citizen IMO.
> from a lazyness and code/knowledge-reuse perspective, I'd prefer using
> Functional Java. I think there are too many Function interfaces in JVM-land
> already (essentially every JVM language that supports first-class functions
> has their own implementation).
+1
Torsten Uhlmann
On Feb 7, 10:00 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
>
> As a proof of concept for Lift/J, I'd like to port the Seven Things code
> base to Java. Basically, this will make use of most of Lift's cooler APIs
> and will likely force a thinking about how to structure the APIs.
>
> I've created a liftj branch in Seven Things where we can do the work. I've
I'll get to work.
> The first pattern I've got (and would really like feedback on this) is the
> "J" Java companion to Scala singletons.
>
> For example, to access LiftRules, you use LiftRulesJ.j() and you've got all
> the LiftRules methods available to you.
>
> Internally, for each singleton, I've got a Scala class named xxxJBridge
> (e.g., LiftRulesJBridge) with has a single method that will return the
> singleton.
>
> In Java-land, I've got the J companion with the static j() method on it. I
> chose a method over a final static because all Lift singletons will be
> mockable in 2.3 (LiftRules and DB are the prime candidates, S and SHtml
> contain no state so they don't need to be mockable.)
>
> What this means is:
>
> LiftRules.addToPackages(...)
>
> becomes:
>
> LiftRulesJ.j().addToPackages(...)
after I tried to work with it...
Concerning the naming (LiftRules vs LiftRulesJ) I tend to think
LiftRulesJ is better. The api between LiftRules and LiftRulesJ will
(probably)
be slightly different. I think a class with the same name should
always have the same signature, otherwise it might get confusing.
>
> I'm also creating Java Func0-FuncXX interfaces with a Func.lift() method
> that lifts the Java representations to a Scala representation. I'm also
> considering sitting Lift on top of Functional Java and use all the stuff
> that the Functional Java guys have already built (with some helper methods
> in either util or common that will bridge the Functional Java stuff to Scala
> stuff.) Any opinions on writing our own vs. using Functional Java?
standpoint it seems like a framework to enable functional programming
in Java, maybe a bit like Google Collections (not comparing the API
though, only the use case) in it's field.
What we try to do with LiftJ on the other hand is building a bridge
between Java and Lift (in Scala), so we have a very specific need.
If we use Functional Java in the LiftJ API then we might hit a wall
where the API they provide does not meet our needs.
But it's entirely possible I'm totally wrong :)
Torsten.
>
> So... thoughts? Feedback?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
Richard Dallaway
Another alternative would be to keep the same class names but have the Java stuff live in a different package (e.g. net.liftweb.java). We could have similar packages for support code for other languages, such as the JRuby stuff.
Richard Dallaway
The first pattern I've got (and would really like feedback on this) is the "J" Java companion to Scala singletons.
For example, to access LiftRules, you use LiftRulesJ.j() and you've got all the LiftRules methods available to you.