java sdk suggestions

[lesterpsigal]

hi,
i'm a intermediate autodidactic java programming beginner with an
experience of programming with < 100 h. i've found the following issues
so far which are topic of my suggestions:

try
{
date: 30.07.2005
no.: 00001
topic: positioning of output view in a jtextarea attached to a
jscrollpane
application: javax.swing classes
version : 1.5.0_03
description: the output view in a jtextarea attached to a jscrollpane
by
default scrolls to the end of that output, a method controlling that
behaviour, like setting the scrollbar position would be helpful, a
workaround could be provided by the jtextarea's select() method
-------------------------------------------------------------------------------------------------------
date: 31.07.2005
no.: 00002
topic: common constructor conception
application: all java classes
version : 1.5.0_03
description: for some purposes it would be a great advantage to have
all
java classes obliged to have a zero-parameter constructor, i.e. a basic
constructor which take no arguments, e.g. for the reason the
newInstance() method of class Class<T> could make use of all java
classes
and not only those providing those zero argument constructor
-------------------------------------------------------------------------------------------------------
date: 31.05.2005
no.: 00003
topic: inconsistency in class superclass handling, when using class
methods
application: java.lang.class<T>
version : 1.5.0_03
description: when invoking the getSuperclass() method on an arbitrarily
java class and subsequently invoking getClass() or getSimpleName() on
that return value the result yields a different interpretation on that
return value:
getClass() yields class, the type of that class and
getSimpleName() yields the actual and distinct class name
--------------------------------------------------------------------------------------------------------
date: 20.11.2005
no.: 00004
topic: extension to javadoc specification
application: java sdk
version : 1.5.0_03
description: it would be good to have a numerical count of all fields,
constructors, methods etc. belonging to a specific class displayed in
the documentation, e.g. in a separate table row, to get a rough
overview
providing to see what comes along e.g when overriding or subclassing a
class
--------------------------------------------------------------------------------------------------------
date: 20.11.2005
no.: 00005
topic: jtable selection settings
application: java sdk swing classes
version : 1.5.0_03
description: the possibilty to set the modal selection of single, or
various rows or columns is missing.
the jtable class offers methods to turn on/off the selectability of
rows, columns in general ( that is for the whole object) but not for
distinct rows, columns or cells (e.g. to disabling the selection option
for the third column in a four column table or the muting of special
cells in a spreadsheet). this could be annoying as possible workarounds
provide too much overhead in proportion of the task to accomplish.
so, the jtable class listener implementation should make use of finer
grained control of its selection listening, this would imply e.g. a
change in the JFileChooser class, where the selection of the type,
size,
datemodified columns and its derived coloured display does not make
that
much sense...
}

catch (FlameThrower fyt)
{
these issues are meant to solely constructive controversial and
provocative
suggestions and mirror my personal opinion
}


lester

 

[Benji]

description: for some purposes it would be a great advantage to have
all
java classes obliged to have a zero-parameter constructor, i.e. a basic
constructor which take no arguments, e.g. for the reason the
newInstance() method of class Class<T> could make use of all java
classes
and not only those providing those zero argument constructor

But this is an awful idea. =) Sometimes you have necessary information
that has to be in the object in order to make it relevant. (for example,
a Socket object has no purpose without an associated actual OS socket
associated with it.

--------------------------------------------------------------------------------------------------------
date: 20.11.2005
no.: 00004
topic: extension to javadoc specification
application: java sdk
version : 1.5.0_03
description: it would be good to have a numerical count of all fields,
constructors, methods etc. belonging to a specific class displayed in
the documentation, e.g. in a separate table row, to get a rough
overview
providing to see what comes along e.g when overriding or subclassing a
class

I'm not sure that this would be any more useful than visual inspection of
the length of the javadoc page for a single class. Numbers of methods
don't really help me make any decision any better, anyway.

 

[Thomas Hawtin]

But this is an awful idea. =) Sometimes you have necessary information
that has to be in the object in order to make it relevant. (for example,
a Socket object has no purpose without an associated actual OS socket
associated with it.

Bad example. Socket does have a no-args constructor, since 1.1.

Still a bad idea, IMO, because:

o Not every class can sensibly provide a no-args constructor.
o Some classes are abstract.
o Some classes limit the way they are created.
o Some classes should not be instantiated at all.
o Class.newInstance is very broken. IMO, use of it should be replaced
using Constructor.


Get yourself a more recent version of Java if you're going to run any
untrusted code...

I'm not sure that this would be any more useful than visual inspection of
the length of the javadoc page for a single class. Numbers of methods
don't really help me make any decision any better, anyway.

How about a lines of code count. :^)

Tom Hawtin

 

[Rhino]

hi,
i'm a intermediate autodidactic java programming beginner with an
experience of programming with < 100 h. i've found the following issues
so far which are topic of my suggestions:

[snip]

If you're seriously proposing these as changes to Java, I believe Sun has a
process for receiving developer suggestions. I'm not sure what it is though
since I've never tried to give Sun a suggestion myself. Perhaps someone else
here can explain that process to you.

I believe you can also accomplish minor changes via bug reports. I seem to
recall that you can supply an RFE (Request For Enhancement) in the same way
as you submit bug reports. I vaguely remember submitting such a suggestion
for the Logging classes but I don't think they chose to implement my idea.

Personally, I think it would be best for you to ask the opinions of others
first and try to build some kind of concensus that your proposals are good
ideas before submitting suggestions to Sun. I assume that's why you are
posting here today

Rhino

 

[Roedy Green]

for some purposes it would be a great advantage to have
all
java classes obliged to have a zero-parameter constructor, i.e. a basic
constructor which take no arguments, e.g. for the reason the
newInstance() method of class Class<T> could make use of all java
classes
and not only those providing those zero argument constructor

For most purposes that is a horrible idea. The reason is a constructor
can ensure an object is complete and logically consistent before being
launched into the world. No-arg constructors necessarily will unleash
malformed incomplete objects on the world that should not be used. You
could not control your objects if you were forced to allow a no-arg
constructor.

Beliefs about abortion of malformed fetuses should not determine
beliefs about aborting malformed objects in Java.

 

[Roedy Green]

topic: extension to javadoc specification
application: java sdk
version : 1.5.0_03
description: it would be good to have a numerical count of all fields,
constructors, methods etc. belonging to a specific class displayed in
the documentation, e.g. in a separate table row, to get a rough
overview
providing to see what comes along e.g when overriding or subclassing a
class

I believe you can do that now. See
http://mindprod.com/jgloss/doclet.html

 

[lesterpsigal]

hi,
i agree, that providing no argument constructors for all classes is a
somewhat odd idea
when certain classes need arguments to be created(especially when
referencing them), i've already understood that idea of conception. but
i've come to that idea when traversing a given class hierachy in a
given (running) class (e.g. 'hangling' through a gui hierachy):
wouldn't it be good to have the possibilty to query dynamically methods
of instances of classes (created by newInstance()) while you don't know
the actual constructor implementation of such classes at the runtime of
the program.

thanks for your feedback

lester

 

[Roedy Green]

i agree, that providing no argument constructors for all classes is a
somewhat odd idea

Imagine a no-arg Integer class for example. Immutability becomes
impossible.