Re: Java 7 features
- From: Guillermo Schwarz <guillermo.schwarz@xxxxxxxxx>
- Date: Tue, 03 Jul 2007 22:59:52 -0000
On Jul 2, 6:20 pm, Tom Hawtin <use...@xxxxxxxxxxxxxxxxx> wrote:
Joshua Cranmer wrote:
@ Closures
But we already have (minimal) closures. I think it would be much more
sensible to improve what we already have, rather than to duplicate. It's
probably unlikely to get in before Java 1.8 anyway.
We already have Runnable. Who needs something else? Although it would
be nice if it were a la Smalltalk:
new Thread( new Runnable() { public void run() { doSomething(); } } );
Would become:
new Thread( <quote> doSomething(); );
Where <quote> could be:
1. [] a la Smalltalk, ie: [ doSomething(); ] It would look ugly in
Java, though.
2. ' (quote) a la Lisp, ie: 'doSomething(); It looks horrible in Java,
so forget about it.
3. # a la Smalltalk, ie: #doSomething(); Not bad, eh?
@ Strings in switch statements
Not too fussed. It'll make switches on strings clearer, but perhaps will
encourage poor code.
Simply use hashCode(), ie:
switch( str.hashCode() )
{
case "hello".hashCode(): ...; break;
case "bye".hashCode(): ...; break;
}
@ Operator overloading for BigDecimal
BigDecimal and BigInteger are hideous to use at the moment. The overflow
semantics of primitive integers are not something that I think should be
in a high level language. I'd prefer general operator overloading of
sensible operators.
It would be nice if all numerical classes in Java were retrofitted to
descend from Number (or implement Number), so that you could declare a
number and it could contain any number: float, int, bigdecimal, etc.
@ Language-level XML support
Evil and unnecessary. A lot like much of XML.
Use XStream instead.
@ Reified generics
This could have made sense in 1.5. But I don't think this is really on
given the situation we have got ourselves into.
What do you mean?
@ Superpackages
Good. I guess packages provide what is necessary from superpackages, but
we tend to write libraries and applications in more than one package.
What is a superpackage?
Is it this? http://blogs.sun.com/gbracha/entry/developing_modules_for_development
I hope not.
First, EJB already have modularization, you deliver 2 jars, one for
use on the client and another for the whole implementation. It is
trivial (some could argue), but it already works.
The same approach could be used for super packages, have some "client"
package and stuff subpackages inside, and another "implementation"
package and stuff everything else, so that all interfaces and Transfer
Objects go into the "client" packages, and the rest have all the
implementations of those interfaces, great!
EJB was a dead horse because the Enterprise Java Beans did not need to
implement the remote interfaces, and besides the home interfaces were
unnecessary. If they had only one interface and one class (it could
have many implementations, but follow the idea for a minute), it would
be nice.
@ Removing checked exceptions
I like static type checking.
Sometimes it gets in the way, but you can always convert those to
RuntimeException, what is the big deal?
Why does people need to force other into their preferences?
Tom Hawtin
.
- Follow-Ups:
- Re: Java 7 features
- From: Twisted
- Re: Java 7 features
- From: Roedy Green
- Re: Java 7 features
- References:
- Java 7 features
- From: Joshua Cranmer
- Re: Java 7 features
- From: Tom Hawtin
- Java 7 features
- Prev by Date: Re: Testing a JVM implementation
- Next by Date: Re: Java 7 features
- Previous by thread: Re: Java 7 features
- Next by thread: Re: Java 7 features
- Index(es):
Relevant Pages
|
