[449] in java-interest
Java quibbles v.2
daemon@ATHENA.MIT.EDU (Douglas Barnes)
Thu Jun 22 19:05:01 1995
Date: Thu, 22 Jun 1995 15:34:38 -0800
To: java-interest@java.sun.com
From: cman@communities.com (Douglas Barnes)
This both adds new quibbles & suggestions and clarifies
some old ones mentioned earlier. These are based on a growing
number of people here at Electric Communities starting to
learn Java and the issues they have encounterd.
It would be very nice, if there are basic structural, security
or other reasons why certain suggestions are infeasible or
otherwise bogus, for the designers to enlighten us as to why
this is so.
In most cases we have been able to figure things out by trial
and error, and to work around limitations in various ways,
but we feel that fixes to these issues might improve things
for others.
Language
--------
o There appears to be no provision for operator overloading.
o There is no "unsigned" modifier, thus generating spammy warnings.
o Array constants cannot be used outside of initialization.
o While there are the System.arraycopy() functions, something
analagous to memset (System.arrayset()?) would be nice.
o The ^ operator, when used on bytes, generates a spammy warning
(it would be a strange implementation that lost precision
XORing two bytes)
o Along the lines of a recent post, we have been wishing for a way
to have variables that can only be written in a constructor, or
that are "public readonly".
o The language has no provision for method pointers.
o The language has no provision for variable #s of arguments.
o While there is a disassembler of sorts, it does not produce
output that can be assembled. There is no assembler of any
sort available, making it hard to test certain assertions about
security (you _know_ that the bad guys are going to have
this sort of thing before too long.)
API
---
o In class BufferedInputStream, does fill() have to be "private"?
Shouldn't it be "protected"?
Documentation
-------------
o There is no example of initialization of arrays from array
constants in the language spec.
o The semantics of "=" and ".equals()" and their relationship to
things that are Objects and things that are not Objects
is not well-documented.
o In the language spec, one is told one can cast arrays into Objects,
and Objects into arrays, but not why, and without explaining
what this might mean.
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
