Some smallish comments on the current version of the spec.
Paul Benedict
pbenedict at apache.org
Wed Nov 28 06:56:34 PST 2012
If Reinier has a better solution, I think a better solution beats any rush
to JDK 8 with a lesser solution. If there is JVM code already written, I
can understand the hesitancy to change things midstream. However, right now
I am only aware of a well-written PDF.
Alex, are you saying that refinements are no longer wanted at this
point-in-time?
Paul
On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:
> Okay, so you're going on record that it's official policy to knowingly run
> with a clearly half-baked proposal, closing the door on any further review
> a scant 3 months after posting a specification (which had already been
> mostly implemented at that point according to the first post on this list).
>
> Not just that, there isn't even an explanation for why this feature is so
> incredibly important that it must be released right now, half-baked. This
> feature seems like the opposite: It enables nothing that can't already be
> done with JDK7. It feels like a coin improvement: Nice syntax sugar but
> that's it.
>
> _THIS_ is getting rushed?
>
> That's surprising, and I cannot find words to express how incredibly
> disappointed I am. Combining java's dedication to backwards compatibility
> with rushed ill-considered specs for no clearly stated reason... do I
> really need to explain how that sounds like a truly horrible plan?
>
> There is a very serious cost associated with carrying on with this proposal
> oblivious to the issues that surround it: There are ways to do this right,
> but by pushing ahead now, you're closing the door on these forever. It's
> java.util.Date + java.util.Calendar, except at the JLS level.
>
> Please, pretty please, with sugar on top, reconsider.
>
More information about the enhanced-metadata-spec-discuss
mailing list