Thanks for the links, Josh. I'm a bit vague on what jigsaw is going to do, exactly. At first there was a big hullabaloo about Sun developing a module system, which then got dragged into a flamewar with the OSGi folks, and which evidently died (JSR 277). Then jigsaw came along, and the first news was constantly predicated with: We're just modularizing the JDK for code quality and loading purposes, that's all, oh, but, maybe, we'll also add a module keyword.
I'm actually happy to hear its moving back into OSGi's territory. Flame on, OSGi folk. On May 21, 4:47 am, Josh Suereth <[email protected]> wrote: > I actually agree with you that the conversations was lacking some context. > I wrote a blog some months back about design using > traits<http://suereth.blogspot.com/2009/02/how-should-traits-in-scala-be-use...>, > however I thought I'd include some new thoughts/insights here. > > There is a method of performing Dependency injection that is slightly more > verbose than guice, but can be done at compile time, without any libraries. > It's merely a design pattern, known as the "cake" pattern. It's actually > how the Scala compiler itself is designed. For a better article on this > technique (not in the show notes) > see:http://jonasboner.com/2008/10/06/real-world-scala-dependency-injectio... > > I'm not an amazing fan of this pattern (although I've used it on a > project). There's a little too much heavy-lifting (basically writing > spring's "BeanContext" in a serious of layers) for my tastes. It does have > the benefit of *not* being a library, (unless you consider scala a library), > but that doesn't hold too much weight for me (I mostly do JEE these days... > so I can deal with a lot of .jar files). One thing I will say is that this > Cake pattern is more flexible than classic dependency injection, as long as > you're willing to write the code. Perhaps IDE support could automate the > generation of "Repository" traits. In the meantime I recommend > reading Scalable > Component > Abstractions<http://lamp.epfl.ch/%7Eodersky/papers/ScalableComponent.pdf>for > no purpose other than to better your existing design skills. > > More importantly, I'm not an amazing fan of this design approach for > "dynamic" modularity. OSGi provides the ability to inject modules into a > running system at runtime. I was talking with a colleague the other day who > actually uses the following system: > > * All aspects of the software are designed as sub-components and > OSGi-modularized > * A DSL (pick any language) is written to configure the appliaction. > (Note Spring 3.0 is supporting this style of configuration, as mentioned in > the Rod Johnson interview podcast) > * A "configuration" module wires the application together. There is a > separate "configuration" module per customer. You can determine the needed > modules for the application by this modules dependencies. > * When doing live upgrades, the new subcomponents are deployed to the > live up and a new "configuration" module is included. If the configuration > module knows how to piece-meal come down and bring up subcompoenents, you > can perform live updates. > > From my colleagues perspect, this architecture was very helpful. I have not > been able to put it into practice, but I keep it in my "bag o' tricks" for > the next application that might require the flexibility. I thought others > may be interested and/or used this technique. > > Anyway, in conclusion: I think the cake pattern is useful and has helped > make me a better programmer but I don't use it on a macro level in > practice. I believe there are other features required (virtual classes > perhaps) that would make modularization better on the whole. It is my > opinion that to help write more modular code, you need to be able to treat a > Large system as a small system i.e. I need to start seeing ways of doing > "module/package inheritance" and "module/package visibilities" etc. Scala > provides a lot of these out of the box (private qualifiers, traits + nested > class ecosystems), but I do not think it's there yet. However, seeing the > new features in Scala 2.8.0, I don't think you'll have to wait long for new > solutions to arise. I think these solutions may require new language > features to become "easy" enough to be widely used. I beleive once Scala > starts utilizing jigsaw/OSGi related features directly, it will become an > ideal language for writing modular software. > > - Josh > > On Wed, May 20, 2009 at 6:31 AM, Reinier Zwitserloot > <[email protected]>wrote: > > > > > Was it just me, or did it feel like that particular aspect of 'scala > > is so cool' totally blew up? > > > creating objects with the 'with' statement just isn't a good way to > > modularize. It would be if: > > > you create 1 scala file that's an app, which creates an object via > > 'with' expansion with just the 'modules' you need, and feed this to > > scalac. If scalac then somehow built a dependency tree and compiled > > exactly every file that's needed to make this work, but no other ones > > (which can involve also picking up .java, groovy, jruby, and jython > > sources!), *AND* this then triggered a cascade that used these sources > > itself as the keys to figuring out which static files and other > > dependencies are required, and then outputted this all to a neat > > little bundle, *THEN* this would be a great modularization tool. And, > > on top of that, to fulfill the stated requirement that clients that > > didn't pay for module X don't even get module X, you should be able to > > state which files should definitely NOT be included, and scalac should > > then generate errors if it cannot complete the compile job without > > compiling those files, which indicates that there are dependencies > > between modules that you never intended and are hence bugs. That'd be > > a fine utility, but scala doesn't do any of this. > > > The only way in which this helps, is if your build tool already has > > the facilities to compile exactly which code you want (and not compile > > the code you DONT want), and the 'with' tactic is used only to create > > a few custom bootstrapping classes. However, if everything's already > > compiled properly because of a build tool, and all you really need to > > do is create a bootstrap class that knows exactly which code entry > > points to fire up, then there are much better tools out there in java > > land (which you can of course use in scala as well!)! > > > - guice should help you with this. Incidentally, guice 2.0 has been > > released this week.http://code.google.com/p/google-guice/ > > > - The SPI system can help here. The custom compile job (e.g. ant > > script) generates the right SPI pointer files, and your one main class > > (instead of the many little ones approach that scala has) will use SPI > > discovery. This is sort of a roll-your-own lightweight guice deal, but > > it has the upside of not requiring an external library*. More info on > > SPI can be found here: > > >http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Prov... > > > *) Is anyone else bothered by the fact that 'requires external > > library' is such an annoyance? That's a rather serious detriment to > > code reuse and the whole schtick where java would rather defer to a > > library that which other languages do in the language space (something > > Joe Darcy, project coin lead, mentions every other email to the coin- > > dev list, for example). I wish java shipped out of the box with a > > lightweight ivy, or better yet, that javac itself compiled to BigJars > > instead of class files and had a feature for stating dependencies in > > source files (per module?) which javac would automatically chase down > > for you. Eh. I'll keep dreaming. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
