And how does simply hiding stuff deal with this "unfortunate" mess:
http://docs.oracle.com/javase/7/docs/api/java/util/class-use/Enumeration.html
No amount of {display: none} in the javadoc CSS will allow those methods to
return an iterator instead, not unless you deprecate them all and implement
new versions with subtly different names, and that's just one of the more
obvious examples!
Jigsaw is the *only* way we'll be able to bump up version numbers and
genuinely remove methods or change their signatures. As you said, this
stuff can be hidden in JavaDoc (hell, ScalaDoc already does something
similar by banishing them to the bottom of the page:
http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.collection.Traversable
)
But... That then has to be reimplemented for each and every tool, in each
and every language running on the Java *platform*. And it *still* doesn't
allow you to change signatures in a backwardly-compatible fashion.
On 19 July 2012 19:51, Jess Holle <[email protected]> wrote:
> How does adding new default packages remove unfortunate historical
> methods?
>
> By adding new copied classes without the methods in question? That's not
> a solution as I see it. By making the new class a base-class of the other
> -- that's not a general solution either due to Java's single inheritance
> model.
>
>
> On 7/19/2012 1:40 PM, Jan Goyvaerts wrote:
>
> 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.
>
>
>
--
Kevin Wright
mail: [email protected]
gtalk / msn : [email protected]
quora: http://www.quora.com/Kevin-Wright
google+: http://gplus.to/thecoda
<[email protected]>
twitter: @thecoda
vibe / skype: kev.lee.wright
steam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not
regard them as "lines produced" but as "lines spent": the current
conventional wisdom is so foolish as to book that count on the wrong side
of the ledger" ~ Dijkstra
--
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.
