Jesper de Jong wrote:Would you mind having a future version of Java which is incompatible with older versions, but which gets rid of old junk? What else would you like to see removed or changed?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Jesper de Jong wrote:
java.util.Date and java.util.Calendar; these should be replaced by something like Joda Time (Project ThreeTen)
Mike Simmons wrote:it should be easy enough to do that any halfway decent programmer could make the changes to an existing project and put out a new fork if necessary, absent official support from the original project. But maybe that's naive.
Mike Simmons wrote:
Hm, I wonder if legacy libraries could be handled with a tool to do bytecode transformation, either at runtime or before.
Pat Farrell wrote:
I'm 100% in favor of removing old crud from the language, and thus from the compiler.
No more Blub for me, thank you, Vicar.
chris webster wrote:As for the transition from "legacy" Java to crud-free "future" Java, the Python world is currently in the middle of just such a transition, as Python 3 is no longer fully backwardly compatible with earlier versions of Python, so it's kind of a pain working out which tools and open-source packages etc you can use with which version of Python. There is a conversion tool, but I don't know how reliable it is.
Pat Farrell wrote:I had high hopes for Scala, but it requires a bigger brain change than I think most programmers and most bosses can handle.
No more Blub for me, thank you, Vicar.
Pat Farrell wrote:I had high hopes for Scala, but it requires a bigger brain change than I think most programmers and most bosses can handle.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Jelle Klap wrote:Nah, I think breaking compatibility anywhere in the near future would be a big mistake.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:For example: an @Legacy annotation for classes like Enumeration (and StringBuffer ) that takes a classname (or set of them) to indicate the class(es) that have superceded the legacy one.
Jesper de Jong wrote:There is already a @Deprecated annotation...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Campbell Ritchie wrote:I remember they were going to prohibit raw types in Java6. And I agree with Jesper that erasure has made generics a right mess. If only they’d had enough time or money or whatever to implement generics in Java1.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Winston Gutkowski wrote:For example: an @Legacy annotation for classes like Enumeration (and StringBuffer ) that takes a classname (or set of them) to indicate the class(es) that have superceded the legacy one.
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Rob Spoor wrote:
Winston Gutkowski wrote:For example: an @Legacy annotation for classes like Enumeration (and StringBuffer ) that takes a classname (or set of them) to indicate the class(es) that have superceded the legacy one.
You mean class literal, right?
I don't think it would work to make the compiler throw errors when you use the legacy classes and interfaces, since they are used in too much existing code; Vector in JTable for instance, and Enumeration all over the place. You couldn't use large portions of the API without turning off these errors, unless Oracle would modify the API to add replacement methods / constructors for all that uses the legacy classes / interfaces. However, if a legacy interface is used by another interface all existing implementations of the second interface would break because they would miss the extra methods.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Martin Vajsar wrote:Sorry to bother you all, but what should be the difference between @Legacy and @Deprecated? Yes, the list of recommended classes would be nice, as well as the "deprecation level", but we don't need a new class of annotation just for that. I seem to miss the point. When would @Deprecated be used and when @Legacy?
(I'm also ignorant about the dire consequences of @Deprecated Winston has mentioned. Quick search in the docs didn't hint anything especially "dire" to me, but perhaps I'm just not sensitive enough )
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Paul Clapham wrote:Here's something I would like to see cleaned up: numbers...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Jayesh A Lalwani wrote:b) Allow interoperatibility using an @Legacy annotation...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Jayesh A Lalwani wrote:
My new Java 7 class can do this
...snip...
but can't do this
...snip...
Consider Paul's rocket mass heater. |