Not a bad summary. The thing is, we don't actually *have* a rug yet. Jigsaw is the rug, and things get swept under it by simply removing them from higher-numbered versions of a module.
To do it in Javadoc and IDEs is more akin to "sweeping it under the furniture". With the catch that we'd have to build a couple of new bespoke additions to our existing furniture for this express purpose. Try putting a new tenant in the house (e.g. Scala, or Groovy) with their own furniture, and the whole exercise has to be repeated. *This*, to my thinking, is the over-engineered waste of time and effort. Java is not just a language, it's a platform. By forgetting that and only focussing on their "catch-up" features, Oracle is once again snubbing the community. On 19 July 2012 18:57, Jess Holle <[email protected]> wrote: > No, that's not an accurate paraphrase at all. I'll try again: > > - Fix and extend the language as appropriate > - Wherever possible without breaking substantial amounts of > existing code, changing its meaning, etc. If you want to go ahead and > break all existing code go somewhere else, e.g. Python 3. > - Not all extensions are good -- care is obviously needed to select > and shape these in keeping with the language. > - Add great *new *APIs. > - *BUT* do *not* waste any significant time and energy trying to > remove clunky old APIs. > > Sweep clunky old APIs under the rug and move on. That sounds harsh and > sloppy, but that's life in the *real *world. Anything else is "ivory > tower" material *unless *you're talking about an embedded or mobile > environment -- in which case, yes, jettisoning cruft (or lazily loading it > on demand) is important. It's a waste of time and energy otherwise. Just > mark the cruft, hide it in Javadoc and IDEs (with an ability to easily > unhide it, of course), and move on. There's no need for the cruft to > bother a non-embedded, non-mobile developer. > > > On 7/19/2012 12:32 PM, Kevin Wright wrote: > > To Paraphrase: > > *Don't bother fixing the language, just offload even more burdens onto > the tooling. Any other attitude is "Ivory Tower" material* > > > I couldn't disagree more. This is the sort of thinking that, IMO, > resulted in the monstrosity we knew and hated as legacy J2EE, the abuse of > SAM types in the swing library, the Calendar class, and the need for > generic parameter folding in IntelliJ. > > Piling yet more levels of over-engineering on a crumbling foundation is > no solution. Every now and again, the only sane practice is to have a > proper spring clean and simply take out the trash. > > That can't happen until we have versioned modules, just in case there > are folk out there who actually still *want* some of that trash... > > > On 19 July 2012 15:51, Jess Holle <[email protected]> wrote: > >> On 7/19/2012 9:38 AM, Kevin Wright wrote: >> >> The loss of Jigsaw is massive and significant. Having modules, >> especially versioned modules, is what will allow the language to evolve. >> >> Sure, it would lead to smaller runtimes, but also to cleaning up >> classes where more than half the methods are deprecated. It would allow >> type signatures to be changed. It would allow Java to (finally!) drop some >> of the baggage that it's been carrying around since before V1.0 >> >> I don't see dropping baggage, including methods as relevant. This is >> "ivory tower" material. It has very, very little impact on the real world >> -- unless one just can't deal with the fact that the real world is not an >> ivory tower. The only thing I believe really should be done here is >> treatment of @Deprecated (or a new @Obsolete) annotation in Javadoc to hide >> all such methods/classes by default -- and to have IDEs do the same. >> That's it -- just hide the cruft by default and you can easily forget it's >> there (unless you're unreasonably anal even for a software developer). >> >> Having a simple, easy-to-use, integrated modularity solution is relevant >> to everyone who hasn't crossed the OSGi chasm. Actually, having modularity >> integrated at the compiler level is relevant to everyone who doesn't need >> hotswapping of modules or juggling multiple versions of the same module in >> the same JVM (really in the same classloader, as one can certainly have >> multiple versions across web apps in the same JVM without OSGi or any such, >> for instance). >> >> -- >> Jess Holle >> >> > > -- 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.
