Declarative transactions, DI, and AOP

[John Vasileff]

I had some success making a small buzzword compliant proof of concept database app that I thought the list may be interested in seeing. Highlights include:

* 100% Ceylon source code and configuration
* h2 in-memory sql database
* ddl/dml using ceylon.dbc
* declarative transactions using Spring
* dependency injection using Spring
* simple aop around advice on data repository operations for performance logging
* 225 LoC (60 of which are import statements!)

The code is available here: https://gist.github.com/jvasileff/1f5fc3bb9b4246620142

Main takeaways:

1) So far the language interop has worked very well. I guess the next step would be to see if Java persistence and mvc frameworks can handle Ceylon classes as pojo model/domain objects.

2) ceylon-compiler issue #1471 should help cleanup some of the extra dependency injection code

3) The module and dependency resolution system doesn’t work for this. Instead, I used gradle to create a fat jar of all dependencies, and brought everything in with a single line in module.ceylon.

4) The IDE can really slow down at times with so many dependencies (13MB jar file.) Typing (autocomplete?) occasionally hangs for 5-10s. This was on an 8GB laptop with -Xmx4096m - maybe it will work better on my desktop machine.


John

[Tako Schotanus]

Thanks John!

Maybe we should find some more permanent place for code examples like this :)

-Tako

John

--
You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.
To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/03788D64-F2DB-4B47-B5B5-A247F36ED47A%40vasileff.com.
For more options, visit https://groups.google.com/d/optout.

[Gavin King]

That's excellent. This is exactly the kind of thing we need to point
people to from the Ceylon website.


More inline...

On Tue, Jan 20, 2015 at 6:59 PM, John Vasileff <jo...@vasileff.com> wrote:

> 3) The module and dependency resolution system doesn’t work for this.
> Instead, I used gradle to create a fat jar of all dependencies, and brought
> everything in with a single line in module.ceylon.

We better make sure we know exactly *why* it doesn't work here.

> 4) The IDE can really slow down at times with so many dependencies
> (13MB jar file.) Typing (autocomplete?) occasionally hangs for 5-10s.
> This was on an 8GB laptop with -Xmx4096m - maybe it will work better
> on my desktop machine.

Have you tried filtering out some packages. The latest IDE lets you do
that. Go to:

Preferences > General > Editors > Ceylon Editor > Ceylon Completion


--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[John Vasileff]

> On Jan 20, 2015, at 8:35 PM, Gavin King <gavin...@gmail.com> wrote:
>
> On Tue, Jan 20, 2015 at 6:59 PM, John Vasileff <jo...@vasileff.com> wrote:
>
>> 3) The module and dependency resolution system doesn’t work for this.
>> Instead, I used gradle to create a fat jar of all dependencies, and brought
>> everything in with a single line in module.ceylon.
>
> We better make sure we know exactly *why* it doesn't work here.

I believe everything is covered in the issues below and also in previous posts here. IIRC, the true blockers are 1) inability to deal with the packaging of some modules, like Google Guava, 2) limitations or difficulty “fixing up” modules, such as overriding dependencies, selecting optional packages, etc, and 3) for anything slightly more complicated (where this bundling hack won’t work), version resolution.

https://github.com/ceylon/ceylon-module-resolver/issues/81
https://github.com/ceylon/ceylon-module-resolver/issues/113
https://github.com/ceylon/ceylon-spec/issues/1134

>
>> 4) The IDE can really slow down at times with so many dependencies
>> (13MB jar file.) Typing (autocomplete?) occasionally hangs for 5-10s.
>> This was on an 8GB laptop with -Xmx4096m - maybe it will work better
>> on my desktop machine.
>
> Have you tried filtering out some packages. The latest IDE lets you do
> that. Go to:
>
> Preferences > General > Editors > Ceylon Editor > Ceylon Completion

Thanks for the tip. It *seemed* to help after a quick test. I guess it may be a good short term workaround, but I’d prefer not to lose autocompletion. In this case, there are only 6 second level package names, but probably too many third levels to sort through. All told, the there are ~9400 imported Java classes, which doesn’t sound like a huge number to me.

John

[Gavin King]

On Wed, Jan 21, 2015 at 3:42 PM, John Vasileff <jo...@vasileff.com> wrote:

> I believe everything is covered in the issues below and also in previous
> posts here. IIRC, the true blockers are 1) inability to deal with the
> packaging of some modules, like Google Guava, 2) limitations or difficulty
> “fixing up” modules, such as overriding dependencies, selecting optional
> packages, etc, and 3) for anything slightly more complicated (where this
> bundling hack won’t work), version resolution.
>
> https://github.com/ceylon/ceylon-module-resolver/issues/81
> https://github.com/ceylon/ceylon-module-resolver/issues/113
> https://github.com/ceylon/ceylon-spec/issues/1134

OK, thanks.

> Thanks for the tip. It *seemed* to help after a quick test. I guess it may
> be a good short term workaround, but I’d prefer not to lose
> autocompletion. In this case, there are only 6 second level package
> names, but probably too many third levels to sort through. All told, the
> there are ~9400 imported Java classes, which doesn’t sound like a huge
> number to me.

Yeah so y'know what we should do: actually *profile* the
autocompletion popup and see where the bottlenecks are. FTR, I have
done essentially zero optimization of this stuff.

[Stéphane Gallès]

Le mercredi 21 janvier 2015 18:32:25 UTC+1, Gavin King a écrit :

On Wed, Jan 21, 2015 at 3:42 PM, John Vasileff <jo...@vasileff.com> wrote:

> I believe everything is covered in the issues below and also in previous
> posts here. IIRC, the true blockers are 1) inability to deal with the
> packaging of some modules, like Google Guava, 2) limitations or difficulty
> “fixing up” modules, such as overriding dependencies, selecting optional
> packages, etc, and 3) for anything slightly more complicated (where this
> bundling hack won’t work), version resolution.
>
> https://github.com/ceylon/ceylon-module-resolver/issues/81
> https://github.com/ceylon/ceylon-module-resolver/issues/113
> https://github.com/ceylon/ceylon-spec/issues/1134

OK, thanks.

IMHO the worst part of this Java libs interop problem is that I believe that it deters people from providing the Ceylon community with "real life Java interop" code examples (nice work BTW John)
Even if you super motivated and overcomes all the obstacles (with hacks like Gradle scripts and fat-jars, been there done that) you can't really publicize the result because it is
experimental, and it would give a bad (and frankly unfair) image of Ceylon. It is a pity because the Java interop of Ceylon at the language level per se is great.

One year ago I had a DropWizard example working (with a fat-jar), and I wanted to blog about it, but I refrained from doing so because because of this specific Java libs interop problem.
That was my two cents, now I shut up. 
 

[Gavin King]

On Wed, Jan 21, 2015 at 10:21 PM, Stéphane Gallès
<stephan...@gmail.com> wrote:

> Even if you super motivated and overcomes all the obstacles (with hacks
> like Gradle scripts and fat-jars, been there done that) you can't really
> publicize the result because it is
> experimental, and it would give a bad (and frankly unfair) image of Ceylon.
> It is a pity because the Java interop of Ceylon at the language level per se
> is great.

I'm not sure it's *that* much of a hack, in fact, I was thinking it
was a sorta reasonable fallback solution that "always works".

Still, I think that it would be nice to somehow formalize the idea of
being able to just package up several jars onto a single classloader.
At some stage Stef suggested doing this be default with mvn
dependencies, but in fact I'm not sure if it needs to be specific to
mvn. Why can't we just let you specify that certain jars all go onto
the same classloader?

[John Vasileff]

> On Jan 21, 2015, at 7:06 PM, Gavin King <gavin...@gmail.com> wrote:
>
> On Wed, Jan 21, 2015 at 10:21 PM, Stéphane Gallès
> <stephan...@gmail.com> wrote:
>
>> Even if you super motivated and overcomes all the obstacles (with hacks
>> like Gradle scripts and fat-jars, been there done that) you can't really
>> publicize the result because it is
>> experimental, and it would give a bad (and frankly unfair) image of Ceylon.
>> It is a pity because the Java interop of Ceylon at the language level per se
>> is great.
>
> I'm not sure it's *that* much of a hack, in fact, I was thinking it
> was a sorta reasonable fallback solution that "always works”.

It’s a huge hack! Not only is it a PITA, but it rules out any reasonable opportunity to import *other* modules that also depend on some of the same classes. With this, there can be no ecosystem, or even loosely coordinated module sharing within a team or organization, but only monolithic beasts.

I feel that Stéphane’s comments are correct, and they perfectly describe my experience. I tried this in November, failed, posted here and got helpful and friendly responses, but ultimately moved on out of frustration until I tried again a couple days ago.

As a big fan of Ceylon the language, this is frustrating. IMHO the success of the language is currently bounded by the success of the module system.

> Still, I think that it would be nice to somehow formalize the idea of
> being able to just package up several jars onto a single classloader.
> At some stage Stef suggested doing this be default with mvn
> dependencies, but in fact I'm not sure if it needs to be specific to
> mvn. Why can't we just let you specify that certain jars all go onto
> the same classloader?

For the reasons above, and also reasons mentioned on GitHub, I’m doubtful that a hybrid system would work. It may help in some scenarios, but I wouldn’t be comfortable relying on a system that may stop working once a certain complexity is reached or when unpredictable changes occur in dependencies of dependencies.

What I would really, really like to see is an alternate “classic” mode that delegates *all* build and runtime responsibility for dependency management and classloading, allowing third party tools and execution environments to be used while Ceylon the language, Ceylon the module system, and Ceylon the platform mature at their own paces. If there’s any interest in such a thing, I’d love to share further thoughts. The idea would be to encourage the use of the current system, but not let it get in the way for projects that need more.

John