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]
<mailto:[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]
<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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:javaposse%[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.
--
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.
