Re: Java language and library suggestions
chucky wrote:
If I have a suggestion for extending the Java language and library,
what is the right place to discuss it?
It should eventually go the relevant JCP JSR.
But you can start by hosting here to see how people like it.
1. introduce method
int String.byteLength(Charset charset);
that would return the length of the string in bytes in the given
charset. This would avoid calling String.getBytes(charset).length,
thus avoid allocating the byte array.
It would. But it would not save much time. It would still need
to iterate and generate all the bytes - just not saving them.
But I think it would be as useful as many existing methods, so
I would not complain if it was added.
I think it should go into CharsetEncoder not String though.
2. allow to specify character encoding for PrintStream. Java 6 SE's
PrintStream prints the characters in platform's default character
encoding.
I believe there already are constructors that supports that.
3. Catch multiple exception types at once. The syntax could be
something like
try {
...
} catch(MalformedURLException, UnsupportedEncodingException as
IOException e){
// handle IOException e
}
I like the comma separated list idea.
4. Sometimes having to catch an exception that will never be thrown is
really annoying.
For example, I would like to write something like
@safe
URI uri = new URI("http://valid.uri.com/");
instead of
URI uri;
try {
uri = new URI("http://valid.uri.com/");
} catch(URISyntaxException e) {
throw new AssertionError(e);
}
I used the annotation notation, but I doubt something like this can be
achieved with annotations. It would be nice if the language had a
construct to mark some code exception safe and if it threw an
exception, it would result in AssertionError. It could also be more
flexible, like this
@safe(NumberFormatException, UnsupportedEncodingException)
{
// statement that should not throw any NumberFormatException or
UnsupportedEncodingException
// and if it does, it is an AssertionError
}
I don't like that idea.
It is relative rare that you will need that (because even though the
code may not throw the exception now, then it may in the future), so
I think it is OK to ask people to explicit code for it.
Arne