Skip to main content

Questions about sillyness(?) in the Java API's

8 replies [Last post]
biehl
Offline
Joined: 2003-06-19
Points: 0

Why (oh why), is there a TimeUnit.SECOND.sleep(500), and not

Thread.sleep(TimeUnit.SECOND, 500) - or even better
Thread.getCurrentThread().sleep(TimeUnit.SECOND, 500)

----------

Why (oh, why), is InetAddress.getByAddress on byte's (and not on shorts - or
anything else for which >127 is a valid value)

and why is it not a vararg - InetAddress.getByAddress(Short... bytes)

HttpURLConnection conn = (HttpURLConnection) url
.openConnection(new Proxy(Proxy.Type.HTTP,
new InetSocketAddress(InetAddress
.getByAddress(new byte[] { 10, (byte) 255,
(byte) 237, 5 }), 8887)));

---------

Why is java.util.Scanner not "Closable" ?

---------

Why does Scanner find an "end of content" on

URL url = new URL("http://www.winehq.org/hypermail/wine-patches/2005/07/thread.html");

before the end with

String contents = scanner.useDelimiter("\\z").next();

but not with

String contents = scanner.useDelimiter("\\Z").next();

(which finds the correct end) - maybe the difference between "\\z" and "\\Z"
could be explained a little better.

---------

Why does Character.LINE_SEPARATOR return a 'byte' and not a char?

(and how does this affect the harmony with StringBuilder .append(char/int/String) )

---------

Why does the following throw an java.lang.UnsupportedOperationException

import java.util.*;

public class test {
public static void main(String[] args) {
List intlist = Arrays.asList(1,2,3,4,5,6,7);
System.out.println(intlist);
Iterator iterator = intlist.iterator();
while (iterator.hasNext()) {
int element = (Integer) iterator.next();
if(element == 2 || element == 5){
iterator.remove();
}
}
System.out.println(intlist);
}
}

when this doesn't

import java.util.*;

public class test {
public static void main(String[] args) {
List intlist2 = Arrays.asList(1,2,3,4,5,6,7);
System.out.println(intlist2.getClass().getName());
List intlist = new ArrayList();
intlist.addAll(intlist2);
System.out.println(intlist);
Iterator iterator = intlist.iterator();
while (iterator.hasNext()) {
int element = (Integer) iterator.next();
if(element == 2 || element == 5){
iterator.remove();
}
}
System.out.println(intlist);
}
}

------------
Why is java.util.Map

public interface Map{
...
public V get(Object key)
...
}

and not

public interface Map{
...
public V get(K key)
...
}

??

-----------------
Why is javax.naming.InitialContext not changed to have the constructor

public InitialContext(Map<?,?>) or public InitialContext(Map)

instead of

public InitialContext(Hashtable<?,?>) - shouldn't hashtable be deprecated
and collections interfaces be preferred?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
gfx
Offline
Joined: 2003-06-14
Points: 0

Well because it's much more easy to understand what addMouseListener(l) does than addListener(l). Sure you can name your variables accordingly but I'm sure it would piss off a lot of developers.

flozano
Offline
Joined: 2004-01-22
Points: 0

I remember many articles stating Vector and Hashtable were deprecrated, but I could find no pointer to that. The official API docs never stated that. The only hint from the J2SE API Javadocs is found in java.util.Enumeration:

"NOTE: The functionality of this interface is duplicated by the Iterator interface. In addition, Iterator adds an optional remove operation, and has shorter method names. New implementations should consider using Iterator in preference to Enumeration."

But the advice to use the collection interfaces instead of classes seems to be ignored all around the Java API, as they use Vector instead of List and Hashtable instead of Map. Besides that, lots of places use Enumerations instead of Iterators.

I understand the problems with backwards compatibility, but why not doing the same as with Data / Calendar? Add new methods using List, Map and Iterator, and deprecate the ones using Vector, Hashtable and Enumeration? 1.5 could have done that...

But as for API sillyness My prefered one is the Swing/AWT add*Listener methods. Instead of

public void addActionListener(ActionListener listener);
public void addWindowListener(WindowListener listener);
public void addMouseListener(MouseListener listener);

And so on, why not just one overloaded method:

public void addListener(ActionListener listener);
public void addListener(WindowListener listener);
public void addListener(MouseListener listener);

tackline
Offline
Joined: 2003-06-19
Points: 0

Conventional wisdom suggests that replacing non-private member variables with getter and setter methods allows implementations to freely choose representation. Conventional wisdom is wrong. And the Java library is not too good about following it either.

Changing the event idiom from using addXxxListener to addListener wouldn't be popular. What would you do with a MouseInputListener? Many people like to use multiple implementation instead of anonymous inner classes (the technique can have some uses when trying to reduce object count, class size and load time).

As I've said many times before the trouble with anonymous inner classes is that the syntax is far too verbose. We should be able to write:

component.addActionListener(new ()(ActionEvent event) { ...});

sat1196
Offline
Joined: 2003-11-08
Points: 0

What if an object implements both MouseListener and ActionListener???
It would be pretty error-prone don't you think?

jimothy
Offline
Joined: 2003-08-06
Points: 0

As to why not Thread.getCurrentThread().sleep(): How could you make any thread other than the current thread sleep? If it's not running, it surely can't sleep! In other words, there's no ambiguity, so it works perfectly well as a static method on Thread, since "make the current thread sleep" is understood.

tackline
Offline
Joined: 2003-06-19
Points: 0

Sleeping another thread, although not a particularly smart thing to do, makes logical sense. For instance:

otherThread.suspend();
try {
Thread.sleep(100);
} catch (InterruptedException exc) {
otherThread.stop(exc);
} finally {
otherThread.resume();
}

Probably not recommended.

tackline
Offline
Joined: 2003-06-19
Points: 0

I'm not claiming that all of the Java library is sane, but I don't think you've got a very good selection there.

> Why (oh why), is there a TimeUnit.SECOND.sleep(500),
> and not

Bare in mind that TimeUnit is in the concurrent package, so we know what is about. It's use is more concise than your suggestions, doesn't overload a method with different interpretation of parameters and doesn't have the confusion between whether it is called on a Thread object or is static.

> Why (oh, why), is InetAddress.getByAddress on byte's
> (and not on shorts - or

IP (v4) addresses are represented by a sequence of octets. Do we have an eight-bit type? I believe we do.

> .getByAddress(new byte[] { 10, (byte) 255,
> (byte) 237, 5 }), 8887)));

Really, how often to you hardwire IP addresses like that?
> Why is java.util.Scanner not "Closable" ?

See other thread. Although I am curious as to what it does with the exception.

> Why does Scanner find an "end of content" on

Is that an API question? Does the page in question end with a new line?

> Why does Character.LINE_SEPARATOR return a 'byte' and
> not a char?

A better question is why isn't it an int or a type-safe enum. Indeed 1.5's getType returns an int. Having the same numerical value as '\r' appears to be a pun if anything. You shouldn't take puns too far.

> Why does the following throw an
> java.lang.UnsupportedOperationException
[removing an element from an a List returned by Arrays.asList]

How do you propose Arrays should shorten an array? Note, it's Arrays.asList, not Arrays.toList.

> Why is java.util.Map
[get(K key) vs get(Object key)]

It's legitimate to look up a value with a key reference who's static type is a super type of the type required. There's no point in forcing an instanceof check. In general it's not going to avoid a cast in the map.

What you really want is something like:

V get(SUPER_KEY key);

But that wouldn't do anything different.

> Why is javax.naming.InitialContext not changed to
> have the constructor

For a start Map does not have a public clone method. It gets messy to faithfully honour the old contract and behaviour if you switched. Might as well stick with it.

Map is not particularly useful as values are often not strings. Keys always are.

> public InitialContext(Hashtable) - shouldn't
> hashtable be deprecated
> and collections interfaces be preferred?

I believe that the old collections are not deprecated because they have widespread use in public APIs and are still the only option on many J2ME systems (without downloading unnecessary classes).

biehl
Offline
Joined: 2003-06-19
Points: 0

Hi,

Thanks for the reply.

> I'm not claiming that all of the Java library is
> sane, but I don't think you've got a very good
> selection there.

Well - some of my questions were from lack of understanding (like the Map[get(K key) vs get(Object key)]).

But I still feel that the other issues are API-sillyness. Which issues do you think are a good selection of "api-sillyness".

>
> > Why (oh why), is there a
> TimeUnit.SECOND.sleep(500),
> > and not
>
> Bare in mind that TimeUnit is in the concurrent
> package, so we know what is about.

Well - "sleep" still doesn't seem like a natural operation for a "TimeUnit" - threads sleep, timeunits don't. No?

> It's use is more
> concise than your suggestions, doesn't overload a
> method with different interpretation of parameters
> and doesn't have the confusion between whether it is
> called on a Thread object or is static.

I know that the static method "sleep" on Thread is no beauty either - therefore the suggestion

Thread.getCurrentThread().sleep()
or maybe
System.getCurrentThread().sleep()

>
> > Why (oh, why), is InetAddress.getByAddress on
> byte's
> > (and not on shorts - or
>
> IP (v4) addresses are represented by a sequence of
> octets. Do we have an eight-bit type? I believe we
> do.

Yes, but the value range doesn't seem to fit?

>
> > .getByAddress(new byte[] { 10, (byte)
> 255,
> > (byte) 237, 5 }), 8887)));
>
> Really, how often to you hardwire IP addresses like
> that?

True. But this was the first and only time (so 100% of the times I've tried)

> > Why is java.util.Scanner not "Closable" ?
>
> See other thread. Although I am curious as to what it
> does with the exception.

Just tried searching the forum - but didn't find it. Link?

>
> > Why does Scanner find an "end of content" on
>
> Is that an API question?

No - more a question to the javadoc - I guess it didn't belong here.

(but still - what is the difference?)

http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html

> Does the page in question
> end with a new line?
>
> > Why does Character.LINE_SEPARATOR return a 'byte'
> and
> > not a char?
>
> A better question is why isn't it an int or a
> type-safe enum. Indeed 1.5's getType returns an int.
> Having the same numerical value as '\r' appears to be
> a pun if anything. You shouldn't take puns too far.

?? Is a char not the most logical output of a method on Character?

>
> > Why does the following throw an
> > java.lang.UnsupportedOperationException
> [removing an element from an a List returned by
> by Arrays.asList]
>
> How do you propose Arrays should shorten an array?
> Note, it's Arrays.asList, not Arrays.toList.

Ah - I see.

> > Why is javax.naming.InitialContext not changed to
> > have the constructor
>
> For a start Map does not have a public clone method.
> It gets messy to faithfully honour the old contract
> and behaviour if you switched. Might as well stick
> with it.
>
> Map is not particularly useful as
> values are often not strings. Keys always are.
>

Well not in this particular case. The Hashtable that InitialContext takes has only String keys and String values. Right?

> > public InitialContext(Hashtable) - shouldn't
> > hashtable be deprecated
> > and collections interfaces be preferred?
>
> I believe that the old collections are not deprecated
> because they have widespread use in public APIs and

So, I've noticed. But with Hashtable being a "Map" - then changeing the interface shouldn't create problems for old client code?

> are still the only option on many J2ME systems
> (without downloading unnecessary classes).

Hrm. Maybe it would be better to remove the old classes then.

-Anders