Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > 7.0 wishlist?

Reply
Thread Tools

7.0 wishlist?

 
 
Hendrik Maryns
Guest
Posts: n/a
 
      10-30-2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew schreef:
> Andreas Leitgeb schreef:
>>> Indeed, for abstract classes' constructors: public is equivalent to
>>> protected. So public could be mapped to protected for those. I see
>>> no gain from that mapping, and even much less gain from demanding
>>> programmers to change "public" to "protected". Since they are in
>>> that case equivalent, it means it doesn't really narrow accessibility.
>>> (which otherwise is a generally good thing to do, of course)

>
> Hendrik Maryns wrote:
>> I do see a good point here, since declaring it protected will prevent
>> people (that are not in a subclass) from trying to invoke it, which the
>> compiler allows, but then barfs at run time.

>
> Not true. I just tried it, and the compiler complains.
> $ javac testit/AbstractModel.java testit/Foo.java
> testit/Foo.java:51: testit.AbstractModel is abstract; cannot be
> instantiated
> AbstractModel am = new AbstractModel();
> ^
> 1 error
>
> AbstractModel has an explicit public constructor.


Oops, sorry I should have checked that. Then it really makes no
difference, but conceptually, it would indeed make sense to forbid a
public constructor. OTOH, it would mean just having another error messageā€¦

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkkJxYEACgkQBGFP0CTku6P9MQCaA9QGhEctkK BYRb7UWjmVv80z
9+IAn2i0Hyk9yAe4OFBhUOLduivdbujN
=LmUl
-----END PGP SIGNATURE-----
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      10-30-2008
Harold Yarmouth <(E-Mail Removed)> writes:
>There's probably plenty of these floating around already, but here's
>bits of mine:


The process for 7.0 seems to be quite advanced now, and decisions
already seems to be made. So, a wishlist might be more
appropriate for 9.0 (with 8.0 being a maintenance release).

* I want the compiler tool and the database of the JDK as a
part of the JRE.

IIRC there are some new provisions for partial loading or
downloading of the rt.jar. If I remember this right, then
this should lower the cost of the inclusion of additional
parts.

Many programs need a means to store data in a database,
and a single standard database would make such
techniques easier to
- port,
- maintain, and to
- learn.

With a runtime compiler, some part of what is now being
done with scripting languages can be done with Java, but
with faster execution. One could have a plug-in directory
with Java source files which are compiled on demand at
run-time.

* Some standard interfaces for functions, values, and
operations to enhance interoperability between libraries
of different vendors. For example,

public interface Function /* java.lang.Function */
< Range, Domain >{ Range valueOf( Domain value ); }

 
Reply With Quote
 
 
 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      10-30-2008
Mike Schilling <(E-Mail Removed)> wrote:
> True, but placing a newly written class in the same package as a library
> class so that you can access its package-private bits is pretty evil.


Actually, getting access to any bits not normally accessible is *not*
the point of the discussed proposal.
I've posted examples for that already.
A wrapper class can access just as much of the wrapped class
as can unrelated classes in the same package as the wrapper.
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      10-30-2008
On Thu, 30 Oct 2008 15:38:14 +0000, Stefan Ram wrote:

> Harold Yarmouth <(E-Mail Removed)> writes:
>>There's probably plenty of these floating around already, but here's
>>bits of mine:

>

I'd like to see the 'unsigned' property introduced for the primitive
numeric types. It would useful for dealing with message bodies associated
with protocols that specify octet codings. Id actually like an additional
'octet' primitive but that would cause all sorts of upheavals and in any
case the notation 'unsigned byte|int|long' is more general.

OK, so I'm a C retread, but I'd still find this a useful addition to the
language.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      10-31-2008
Whereever I say "something is wrong", that of course only
reflects my own opinion. And this opinion is often (but not
always) a result of a misunderstanding. I'm glad if you
point those out, but please don't ever feel offended by them.
They unfortunately happen sometimes.
Some other disagreements are not about misunderstandings,
but about different views of how it should be.

Harold Yarmouth <(E-Mail Removed)> wrote:
> Lack of methods seems like a pretty big distinction between Cloneable
> (and Serializable) and "normal" interfaces.


So you do intend a special case for marker interfaces so
marker interfaces need to be explicitly "implemented", but all
others are auto-implemented if all it's method signatures exist.
explicitly implementing a non-marker interface then has only
one purpose: let the compiler make sure I didn't forget a method.

Did I get it right? If so, then I do not like it at all.
If it's still a misunderstanding, then my comment obviously
doesn't really apply to your idea.

How would you judge the *runtime* penalty of checking the existence
of all necessary methods upon each attempted cast?

>> from reading <(E-Mail Removed)>.
>> (in case google distorts it: "slrngfmc50.4jb.avl" is the part
>> before the "at")

> Eh -- I don't read using Google, and you don't appear to have posted
> this using Google, so why would Google distort it?

As Lew guessed right, it was intended for anyone who does read the
posting with google. Btw., That doesn't need to be a gmail'er, but
could be anyone just using google's news-archive at a later time,
as I've frequently done myself in the past. There is no such thing
as a private conversation in a newsgroup.

>> As I brought it, it would subsume the functionality
>> of proposed typedefs plus add some more useful usecases.


> With the added proviso that extensions of final classes can't see their
> protected fields and methods. Essentially, "protected == private if the
> class is final" would be maintained.

Yes (furthermore leaving aside the "same-package" special case).
I'd even go further to do this regardless of final'ity
of the wrapped class. It doesn't seem right to me for a
class that *doesn't really* subclass a given class to still
access it's more-restricted bits.

>> Sounds cool, principially, but I don't like to add a "line noise
>> character" for that feature, but rather some keyword.

> Verbiage alert. This is a slight modifier that would be very
> common on reference declarations,

In some way you're right, but Joshua also made a good point
recently by quoting a sample of some new keyword-less syntax
of some "newer C++": just seeing the new syntax makes it
almost impossible to look it up in order to get to know
what it means.
As soon as some keyword or other constant verbiage is used,
it becomes possible to look it up.

However, there are new problems I see with it (non-nullness) now:
Assume I wanted to use a HashMap<String,Integer*> I'd expect it
to only contain non-nulls, but get() would still produce nullable
values, as it returns null for unknown keys. HashMap's implementation
is ofcourse not aware of whether it's Value type is nullable, so it
has no clue as to how to declare it still-nullable when it returns
the Type parameter or null. There may exist solutions, but I fear
it's getting more and more complex, rather than just the simple
nonnull marker you started out with.

> String*[] noNullsArray = array; // Runtime check that no element
> // is null gets generated here.

Huh!? I thought the whole point of it was to guarantee null-freeness
at compile time.
Compare it with ClassCastExceptions: they can only be thrown at explicit
casts (implicit casts are only possible where no runtime-check is necessary)

Alternative: new method in java.utils.Arrays such that
noNullsArray=Arrays.nonNull(array);
will assign the instance only after a successful runtime nonnull check
(otherwise throw a NullPointerException immediately)

> String*[] another = {"Foo", "Bar", "Baz"};

Ok, that's fine, but a special case (only hardwired number
of elements possible).

> Of course we could get into hairiness with noting whether the array
> reference itself can be null:
> String*[]* -- which * means which?

That will need some more and better ideas, expecially also for
multidimensional arrays (i.e. arrays of arrays of arrays ...).
I like the principle, though.

>>> * Allow omitting the names of unused parameters. Common cases would include:
>>> public void ActionPerformed (ActionEvent) {

>> Really little gain, ...

> The cases I was thinking of are e.g. [...]

catch (IOException _) {
.... = new ...() { public void actionPerformed (ActionEvent _) {

These cases hardly ever accumulate, but if they do, there's still
"__" and "___" and ... as further dummy names.

(I admit that these cases were not covered by my previous arguments.)

> I'm just asking for
> Map<Key,Value> map = new HashMap();
> without any need to repeat the <Key,Value>, that's all!

Sorry, my misunderstanding once again.
I think I've read that this particular syntax will indeed
be added in 7.0 (regardless of this discussion here).

> StringBuilder sb = new(10);

I don't like that at all.

> classes be both uninstantiable and unsubclassable. As things stand, you
> have to put a private no-argument constructor in, which says the same
> thing as "final" but in a much more verbose and less readable manner.


My point is that I see no relevant need to prevent anyone from
instantiating or subclassing a Utility class, e.g. like java.lang.Math.
What bad could one do with it, if it were possible?

Playing around I tried this ugly idiom:
class Test { static Math m; static { m.sin(m.PI); } }
interestingly the bytecode contains "getField m"
immediately followed by "pop".

> I think you've misunderstood me. The point was that this would be a
> corner case, where the compiler would think that an exception could be
> thrown somewhere where it actually wouldn't occur for exactly the
> reasons you state.

What did you mean should actually happen to checked exceptions
thrown within run() (and not caught there)?

> Why not just least common denominator?

Because such an array may not be compatible with what I want to use it
for:
void foo(Number[] a) ...
foo({1,2,3,5,8,13}); // wouldn't work, because the auto-inferred
type would be Integer[] which is not castable to Number[].

>> Another entirely different approach could be an
>> "exemptfromtry { ... }" block inside the try-block.

> Oh, my God. Uggg-leee!

It's a generalisation. it's about like
try { ... errors caught }
continue { ... errors not caught }
tryalso { ... errors caught again }
continue { ... errors not caught }
tryalso { ... errors caught again }
catch ...
finally ...

except it could be even nested:
try {
for (...;...;...) { // loop header may throw excs to be caught.
dontcatch { doSomething(); } // propagate all errors from that call.
}
} catch (...) { ... } finally {...}

I don't think I'd need the feature myself, but it does
appear to have an aura of usefulness
Someone else would have to find a better verbiage for it.

Oh, and the finally block would still need to be executed
even if it was doSomething() that threw an exception.

> The existence of IdentityHashMap is proof that someone at Sun also
> thought that such a thing could be useful. They just didn't generalize it.

That's a very very special and otherwise rare usecase (serialization helper).

Don't let my opinion against it discourage you.

> ReferenceQueue already exists and somewhere there is code that enqueues
> references on them. So the "hooking into the GC" at issue here is
> already being done.

Sun did a few special tricks to prevent users from hooking in.

I do not exactly understand Sun's reasons for that, but it most
definitely hasn't just been forgotten - it has actively been
worked against by sun.

> As it is, I think the effect can be achieved by making a Thread that
> calls the blocking poll method

There is no blocking poll for the ReferenceQueue, and also no way to
create one as derivative. The thread would have to run a busy loop
(yuck!).

>> I don't get that at all. What Subclasses are you now talking about?

> Referring to the enum implementation, which has the enum constants
> actually singleton instances of same-named subclasses.

Thanks for explaining. I really didn't know that.

> Not on disk, no, but there are four classes in the system at runtime;
> some ClassLoader magic sees to that.

Strange. I utterly fail to see the reason behind that.

>> The case I could imagine was a SubEnum, that allowed a free
>> selection of a subset of BaseEnum's instances, and otherwise
>> behaves like a wrapper based on my own class-wrapper proposal
>> (messageid [still quoted somewhere above] ).

> Wrap, reduce range, or both. Yep.


>> * Now finally, I add one more idea to the list:
>> Distinguish between "using" and "implementing" an interface with
>> respect to accessibility.
>> The point being to allow to publish an (internal) interface
>> for return values (cookies), that foreign code may use as type
>> for variables, but not in "implements"-lists for classes.


> There's already a few other ways to do this:


But none of them (including even my WeakHashMap approach)
allow checking at compile time, as the proposed change would.

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      10-31-2008
Hendrik Maryns <(E-Mail Removed)> wrote:
> I do see a good point here, since declaring it protected will prevent
> people (that are not in a subclass) from trying to invoke it, which the
> compiler allows, but then barfs at run time.

That has already been corrected by Lew.

>> Comparator mostly exists because not all classes are
>> per se Comparable, ...

> And also because from time to time, you want to use a
> non-default sort order (like reverse, or just on another
> field as you usually sort on).


You're entirely right wrt. Comparable. Yet I haven't yet
had a use for a different equality imposed on a class from
outside. Harold already mentioned the IdentityHashMap and
its use. Btw., that class uses: System.identityHashCode()
(that's the one I didn't find before)

I don't think there is any pressing need to make that static
method of System also a final method of Object.

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      10-31-2008
Joshua Cranmer <(E-Mail Removed)> wrote:
> Knowing how enums are implemented, you'd basically have to change nearly
> every aspect of implementation. I don't see how you could make this
> possible:
>
> public enum SomeEnum {
> A { void foo() { "Foo!"; } },
> B { void foo() { "Bar!"; } },
> C { void foo() { "Ugh!"; } };
> abstract void foo();
> }
>
> public enum Enum2 extends SomeEnum {
> A, B;
> }


It would have to work almost, but not exactly like the wrapping
previously described for classes. That way, SomeEnum.A and .B
become also be subclasses (and instances) of Enum2.
That SomeEnum.C would *not* be a subclass (instance) of Enum2
does contradict the proposed wrapper properties, but then again,
it's about enums here, not classes. enums already have all sorts
of special cases, already.

There are more technical problems to solve before this could even
possibly become a feature, like the instances' .value(), if e.g.
not C, but A was omitted. I do think it could be solved.
E.g. SubEnums would not be required to have a continuous range of
values starting with 0. They'd just mask out the instances not
selected. Also, Enum2 couldn't specify anonymous subclasses, of
course, since the instance is already there from BaseEnum.
public enum Enum2 subselects SomeEnum {
A { ... } // no no!
}

I like the idea of subselections, but not for any high price.
Wrapping classes is fine. If it turns out not to be compatible with
subselections, then so be it

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      10-31-2008
Andreas Leitgeb <(E-Mail Removed)> wrote:
>>> I don't get that at all. What Subclasses are you now talking about?

>> Referring to the enum implementation, which has the enum constants
>> actually singleton instances of same-named subclasses.

> Thanks for explaining. I really didn't know that.


Looking at what "javap -verbose java.lang.Thread.State"
prints out, I now have some doubts:

static {};
Code:
Stack=4, Locals=0, Args_size=0
0: new #33; //class java/lang/Thread$State
3: dup
4: ldc #2; //String NEW
6: iconst_0
7: invokespecial #61; //Method "<init>"Ljava/lang/String;I)V
10: putstatic #52; //Field NEW:Ljava/lang/Thread$State;
.... (ditto for the other fields)

Whether there exists a hidden class for Thread.State.NEW,
called into existence by the jvm, or not, the actual instance
is being created as Thread$State, not Thread$State$NEW.

Where did you get this information about these subclasses from?

>> Not on disk, no, but there are four classes in the system at runtime;
>> some ClassLoader magic sees to that.

> Strange. I utterly fail to see the reason behind that.


Can you give sample code that makes these extra classes visible?
or an URL to the part of the JLS or jvm-spec?

 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      10-31-2008
Andreas Leitgeb wrote:
> Whether there exists a hidden class for Thread.State.NEW,
> called into existence by the jvm, or not, the actual instance
> is being created as Thread$State, not Thread$State$NEW.
>
> Where did you get this information about these subclasses from?


enum subclasses are only created if you have enum bodies.

public enum Operation {
PLUS { public int op(int a, int b) { return a + b; } },
MINUS { public int op(int a, int b) { return a - b; } },
TIMES { public int op(int a, int b) { return a * b; } },
DIVIDES { public int op(int a, int b) { return a / b; } };

public abstract int op(int a, int b);
}

You will see an Operation$PLUS, Operation$MINUS, etc.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      10-31-2008
Harold Yarmouth <(E-Mail Removed)> wrote:
> Andreas Leitgeb wrote:
>> Mark Thornton <(E-Mail Removed)> wrote:
>>> Harold Yarmouth wrote:
>>>> * Allow extending final classes, subject to the constraint that new
>>>> instance fields cannot be defined and none of the final class's methods
>>>> can be overriden regardless of whether the method is explicitly "final".
>>>> Essentially allows wrapping final classes.
>>> As you wouldn't be able to override hashCode and equals the contract of
>>> these methods would be broken.

>>
>> No it wouldn't. Just because the following things would be
>> forbidden in such a wrapper class:
>>
>> * overriding of any methods (overloading still ok)
>> * implementing any interfaces

>
> Why not?


Implementing an interface is a property that applies
to an instance. A given instance can be queried
about whether it implements a certain interface.

My design for wrapper classes was primarily inspired by the
discussion about typedef, and the wish to extending this trick:
class ShortName extends LongGenericName<With,Lots,Of,Parameters> {}
such, that one could take a LongGenericName<...> instance and
assign it to a ShortName typed variable. For this to work, ShortName
(as a class) has to be restricted somehow. Fortunately those
necessary restrictions did not logically forbid the adding of
new methods, which then led to a new extra usecase of extending
instances of final classes to enjoy new methods. (See the MyString
example in the post whose messageId I gave (a few postings upthread)
for how that could be used.)

Regarding the necessary restrictions for a wrapper class:
An instance is *not* supposed to know whether the
baseclass or the wrapper was used for its creation.
This detail is crucial to the safety of the "upcast"
from baseclass to the wrapper.

If a wrapper-instance did implement an extra interface, then
clearly it would be distinguishable from a baseclass instance
which would not implement it.

Maybe you have a different design in mind. I tend to stick
to mine, until I find one superior to it in all the points I'm
interested in.

>> The expression (new Wrapper()).getClass() would return
>> the baseclass!

> That might be a bad idea.


It is strictly necessary for this particular design of mine.
It may not be for any other design.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments