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.
