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]
<mailto:[email protected]>> wrote:
No, that's not an accurate paraphrase at all. I'll try again:
* Fix and extend the language as appropriate
o 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.
o 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]
<mailto:[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.
