Why not just adding new default packages to replace java.lang & al ? On Thu, Jul 19, 2012 at 8:37 PM, Jess Holle <[email protected]> wrote:
> Tweaking Javadoc and IDE support to hide cruft is simple and effective > as compared to having to refactor the entire JVM class library. It allows > hiding of methods we'd all like to forget, which Jigsaw can't. The only > other way to remove an undesirable method is to actually remove it -- and > break lots of stuff in the process. That's pointless. Just tweak Javadoc > and IDEs and move on -- simple and effective. > > Swinging Jigsaw at this misses the icky method issue entirely and puts far > too high a priority on JVM modularity without cause. > > As I see it, Jigsaw is primarily for modularizing the rest of the world in > a simple, easy-to-use fashion. The rest of the stuff (including > modularizing the JVM) could really be put off until Java 10. > > > On 7/19/2012 1:19 PM, Kevin Wright wrote: > > 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. > -- 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.
