On 7/21/2012 9:48 AM, Kevin Wright wrote:
On 7/20/2012 2:42 PM, Kevin Wright wrote:
Nothing wrong with a half-baked solution. Something can have
definite value even if it's not "complete". But without the
ability to evolve the thing and change APIs under a different
version number, it's too risky to release in such a state.
No module system will give you what you want -- an ability to
radically and incompatibly change longstanding public APIs
whenever and wherever this is deemed more correct/pure/perfect,
e.g. wherever you'd do it differently if you could do it all over
again.
Radically change - yes
Whenever and wherever - no
I'm only concerned with two classes of issue here:
1. The big, infrequent changes: removing Corba, breaking swing out
into a separate module, a one-off replacement of all methods using
enumeration to use iterable. The sort of legacy stuff that you often
hear people wishing could be changed with each new release, but which
is tied to backwards compatibility.
Most of this isn't worth the sort of heartburn / community fracturing it
would engender. Removal of CORBA is a separate case, of course, as this
largely can just be moved to a separate module without actually changing
APIs in any incompatible fashion. Rather it can just be pushed out of
the way. That said, it wouldn't buy me anything whatsoever either --
not because I use CORBA but rather because CORBA packages being present
does not hurt me in any way whatsoever.
2. Very new stuff that's still evolving. Instead of hiding JavaFX 2
from the public for so long, it could have been released as a
versioned module. Frequent changes here wouldn't be a problem in the
same way as for more established functionality, because nobody's yet
had time to build up any legacy code around them.
The extreme way that I works because it happens in a very lean
environment, where the developers are all co-located, the
"application" is made up of numerous modules all communicating via
JSON, and where almost all our services are for in-house consumption
by our own client app.
I can't imagine that approach working in the Java libs for a second.
As you say, that works in a very lean, colocated, environment.
This sort of change would fall on its face for large distributed
environments with large less modular source bases, lots of usages of
external Java libraries, etc.
In short, it wouldn't fly for a good number of large Java-based
development organizations.
--
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.
