On Fri, Jul 20, 2012 at 11:09 AM, Kevin Wright <[email protected]> wrote: > That would be a claim can't be easily demonstrated by citing industry > trends. Then again, I still contend that there is no other proposed > mechanism which would allow deprecated methods to truly be removed, and > method signatures to be changed (both important aspects of keeping up to > date), all without sacrificing backwards compatibility.
I think that is the crux I have been unable to understand. How is it truly possible to support some of the changes that are desired while keeping backwards compatibility? Even with jigsaw. Easy example, how would jigsaw have helped move on to a better api for dates? I can see how it would work in some cases. Smaller example, we have Vector and ArrayList because the api for Vector was synchronized, right? With modules like this, the idea would be that you could change the api between versions. But doesn't that fall completely on its face when you have communication between two modules using this datatype, where one relies on the old api and one the new? Or are we essentially just talking about the ability to have pseudo statically linked applications running in a vm? (In a cleaner way than multiple classloaders?) My jerk comment. OSGi style modularity has not helped Eclipse compete with IDEA. Why do we think it will help everyone else? -- 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.
