My thoughts on them being anti-modular is more around wanting to keep an API separate from -ANY- implementation.
Say you have a bug in your default implementation, or you wish to alter it - you currently need to rerelease the API even tho the actual API hasn't changed. In an ideal modular world we should be shipping -api and -impl jars and keeping things separate, this makes working with say OSGi and I guess any other module system much nicer, clients will bind themselves against an API, which ideally would be rather stable and not change often, leaving the implementation to be interchangable. Maybe this pattern is more suited to more services than utility functions like but in the name of modularity I don't see why it shouldn't be just as desirable. On 30/10/2012, at 11:46 AM, Graham Allan <[email protected]> wrote: > w.r.t. 'anti-modular', I'd like to hear more on what you mean by this. > Do you mean that there's no way to organise default methods except as > being in the same file as the interface declaration? -- You received this message because you are subscribed to the Google Groups "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.
