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

Harold Yarmouth schreef:
> Joshua Cranmer wrote:
>> Harold Yarmouth wrote:
>> A poor way

>
> No, it is not, and I will thank you to stop gratuitously insulting me.
> You, sir, have an attitude problem.
>
> If you have nothing pleasant or constructive to say, might I suggest
> that you keep your mouth shut in the future?


Please keep in mind that telling people what to do on Usenet generally
doesn’t work. If you don’t like what people write, don’t read it, it is
the only way, I am afraid. There are long essays on this topic, which I
will not bother to google up for you Generally, responding to them
is a bad idea, therefore I snipped all other similar comments out below.

>>> * Allow array literals in expressions other than assignment RHS.
>>> Why the devil is foo(1, "string literal", 3) allowed but
>>> foo(1, {array, literal}, 3) is not, even when foo's second
>>> parameter type is Object?

>>
>> new Object[] {array, literal} ?

>
> Works, but if the array doesn't need to be modifiable, creates a
> wasteful duplicate every time.


How so? Isn’t {array, literal} supposed to create one as well? The
method expects an array, after all. Oh, I see, it doesn’t. But even if
it expects an Object, there has to be an Object, so the array needs to
be created.

> If you're worried that letting immutable arrays get used in such
> contexts could somehow cause problems, keep in mind that this is already
> possible:
>
> int[] foo = {1, 2, 3};
> ...
> fooMethod(1, foo, 3);


I don’t get it, foo is mutable.

>>> * Have array constructors added to the collection classes:
>>> (with the above as well)
>>> new HashSet({2, 3, 5, 7, 11, 13});
>>> new ArrayList({"foo", "bar", "baz", "quux"});
>>> new HashMap({{"key1", "value1"}, {"key2", "value2"}});

>>
>> new HashSet(Arrays.asList(2, 3, 5, 7, 11, 13));
>>
>> So much cleaner IMO.

>
> You're joking, right? It makes an unnecessary temporary collection.


True, but ISTR that in Java, creating and abandoning a lot of small
classes if more efficient than clinging to one big class. So I wouldn’t
worry about this small class that gets created here. That’s the GC’s
responsibility.

> In
> fact, all the collections really ought to have constructors that take an
> Iterable and just iterate over it.


That seems like a good suggestion, indeed.

> In many cases, they can be
> implemented in all of two lines of code:
>
> super();
> addAll(iterable);
>
> given that addAll gets broadened to allow any iterable.


Which would be consequential (in the sense of being consequential) on
allowing the constructor to take one.

> Or at least
>
> super()
> addAll(collection);
>
>> There's also this for the last one:
>> new HashMap() {{
>> this.put("key1", "value1");
>> this.put("key2", "value2");
>> }};

>
> Now you're making a whole extra class. How efficient.


How would this be less efficient? You’re creating a HashMap anyway.
Oh, you mean the extra class object. I doubt it will make a difference.

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

iEYEARECAAYFAkkJjvQACgkQBGFP0CTku6M87gCgmHxKuMjdXx Tr62YXIQdp8A/4
vDIAoJCGS9RBfmA7BGGDkEIvdS8MdFH+
=sQhw
-----END PGP SIGNATURE-----
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      10-30-2008
On Thu, 30 Oct 2008 01:21:02 -0700, "Mike Schilling"
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>
>That works fine now.


It might be this is just something IntelliJ lint is picky about, or it
could be the catch as you describe. I have got in the habit of making
throws, throw, catch... match perfectly so I can't remember the
precise problem I used to have.

The problem with what I do now, is that I do a lot of maintenance of
throw, throws, catch at various levels in the hierarchy, which is very
rude in code used by other people. I should give them a stable throws
interface which leaves room for future changes.

I ran into this often writing stub or debug code, then later replacing
it with production code that actually threw the exceptions.


--
Roedy Green Canadian Mind Products
http://mindprod.com
A vote for McCain is fearful clinging to McSame.
A vote for Obama is a shot at Obamalot.
 
Reply With Quote
 
 
 
 
Hendrik Maryns
Guest
Posts: n/a
 
      10-30-2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harold Yarmouth schreef:
> Mark Space wrote:
>> Harold Yarmouth wrote:
>>> * Provide a better way to deal with OutOfMemoryError or low memory in

>>
>> Hmm, I haven't looked at any existing frameworks for using
>> SoftReferences, but I'd head over to Apache.org and take a look.

>
> I'm not presently in the market for a web server, but thanks anyway.


I think you don’t understand. He refered to
http://commons.apache.org/collections/, specifically to
http://commons.apache.org/collection...erenceMap.html.
But note that *the* big disadvantage with Jakarta Commons is no
generics, although finally, there is an effort going on.

>>> * WeakValueHashMap, LinkedWeakHashMap, and LinkedWeakValueHashMap.
>>> These would all be useful implementing caches where you want the

>>
>> I think the Apache folks may have a framework or three. Didn't
>> actually check though...

>
> These deserve to be in java.util.


I tend to agree here, but they have to be cleaned up first. And
generics, of course.

> Plus, nobody goes looking for third party collection classes. They go
> looking for third-party math libraries, web app frameworks, other
> domain-specific libraries, and ImageIO plugins and the like.


Well, they should be. Collection classes are amongst the most difficult
to implement well, IMHO.

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

iEYEARECAAYFAkkJkdQACgkQBGFP0CTku6MDYQCfczXfaee8kE 8wyd7zcMKX+A9O
vmMAn3cE3kWv2hxZOCzPZfYzpcscQcvO
=O6ZH
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Bent C Dalager
Guest
Posts: n/a
 
      10-30-2008
On 2008-10-30, Hendrik Maryns <(E-Mail Removed)> wrote:
>
> Harold Yarmouth schreef:
>> If you're worried that letting immutable arrays get used in such
>> contexts could somehow cause problems, keep in mind that this is already
>> possible:
>>
>> int[] foo = {1, 2, 3};
>> ...
>> fooMethod(1, foo, 3);

>
> I don?t get it, foo is mutable.


In theory, though, a compiler might decide to retain the actual array
object between invocations since its size will always be the same,
it's only the contents that is mutable.

It would have to do a lot of analysis beforehand though, to make sure
no one else has retained a reference from a previous invocation. Seems
a bit dicey overall

Cheers,
Bent D
--
Bent Dalager - http://www.velocityreviews.com/forums/(E-Mail Removed) - http://www.pvv.org/~bcd
powered by emacs
 
Reply With Quote
 
Hendrik Maryns
Guest
Posts: n/a
 
      10-30-2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harold Yarmouth schreef:
> Andreas Leitgeb wrote:
>> Harold Yarmouth <(E-Mail Removed)> wrote:
>> Also, for unused method-arguments, the name is usually referred to
>> by the javadocs. You do javadoc your methods, don't you?

>
> My anonymous inner class actionPerformed methods?
>
> You're joking, right?


I wouldn’t have been. Ok, Javadoc is unnecessary, but for maintenance
purposes some comment makes sence. Might as well be Javadoc
(Alt-Shift-J generates it in Eclipse, and I can never remember the
shortcut to create a block comment, since I almost never use them).

>> 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)

>
> On the flip side, the compiler's not permitting "abstract final" is
> silly, since it would be useful for making one of those static-utilities
> 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.


You are stretching the intended semantics of ‘abstract’ here. It is
meant to mean: this class should be subclassed to fill in functionality.
It is not intended to mean ‘this class has a constructor which you may
not use’.

>>> * Have array constructors added to the collection classes:

>> If the previous item has a solution, then this one can easily be done
>> by appending .toList() to the array-literal.

>
> Wasteful in the extreme. Not just one intermediate object, but probably
> actually N+1, and a whole extra O(N) copy of the collection.


Mind elaborating how you get these numbers? I don’t find that obvious.

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

>
> Oh, my God. Uggg-leee!


But feels more in line with the current syntax to me. I’ve often felt
the need for this.

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

iEYEARECAAYFAkkJm5MACgkQBGFP0CTku6PK4QCfcCulhrfjFp N+dwX4KlCM+t1f
VCYAoLKnHx2oFZ925/Q7SQIG9vbh1PGB
=J8Vt
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      10-30-2008
Harold Yarmouth wrote:
> Joshua Cranmer wrote:
>> Harold Yarmouth wrote:
>>> There's probably plenty of these floating around already, but here's
>>> bits of mine:
>>>
>>> * Sort-of structural typing. Any object can be used where an
>>> interface type is expected if it has the right set of method
>>> signatures, whether or not it "implements" the interface using that
>>> keyword. (It still must to inherit constants defined in the
>>> interface, and methodless interfaces would not get this behavior else
>>> everything becomes, among other things, serializable!)

>>
>> I smell a lot of unexpected bugs coming from this.

>
> How so?


How many interfaces are there in core Java code alone? With these
change, my class would effectively implement dozens of interfaces that I
didn't know exist and whose contracts I am probably violating.

>>> * When a type has a one-argument plus() method, + can be used when the
>>> left hand operand is of that type and the right hand operand is of an
>>> argument type for which the former has a one-argument plus() method.

>>
>> [ ... ]
>>
>> A poor way

>
> No, it is not, and I will thank you to stop gratuitously insulting me.
> You, sir, have an attitude problem.


Then how do you propose to add such features as LHS-based operations,
like 2 * matrix?

> If you have nothing pleasant or constructive to say, might I suggest
> that you keep your mouth shut in the future?


I'm sorry. I assumed you had been a denizen of this newsgroup for a
while and therefore had seen my copious commentary of operator
overloading in the past year or two (which has come up in at least three
separate threads).

>> Except many other languages use == as equivalent to the equals method
>> and === as equivalent to Java.

>
> Other languages are irrelevant.


They are relevant. What you are proposing would be counterintuitive on
multiple levels:

1. Visually === is "more" (i.e., more stringent) equal than ==. That
implies that === would have to become identity equality while == would
become equals()-based equality.
2. This is a COMPLETE reversal of practically every single dynamic
language on here.

Once again, this has been discussed in more detail quite recently
(within the last month, IIRC), so I'll defer to you look at those
threads in question.

> Sure I have. Did you even bother to read my entire post before clicking
> "Take A Crap All Over It And Send" in your news reader?


I reply to large posts as I read them.

>> new Object[] {array, literal} ?

>
> Works, but if the array doesn't need to be modifiable, creates a
> wasteful duplicate every time.


It's doing the exact something the JVM would be doing anyways. In terms
of bytecode, there's no advantage except dropping some extra typing.
Note that Java looks unlikely to drop extra typing merely for the sake
of extra typing based on historical fact.

> You're joking, right? It makes an unnecessary temporary collection. In
> fact, all the collections really ought to have constructors that take an
> Iterable and just iterate over it. In many cases, they can be
> implemented in all of two lines of code:


This is the first suggestion I've seen that would have a very strong
chance of making it in (although not the first worthwhile one, others
were also worthwhile).

>> There's also this for the last one:
>> new HashMap() {{
>> this.put("key1", "value1");
>> this.put("key2", "value2");
>> }};

>
> Now you're making a whole extra class. How efficient.


Doesn't require any changes to existing libraries, the JLS, and the JVM.

>>> Or just allow x?expression1:expression2 for non-Booleans testing
>>> for null.

>>
>> x == null ? expr1 : expr2 is not at all verbose and much easier to
>> distinguish on scanning.

>
> It's slightly more verbose and no easier to scan for.


It's not something I'll belabor, but most people would probably prefer
the second form merely because it obviates that x is an Object and not a
boolean.

>>> * Full closures.

>>
>> Someone beat you to this.

>
> Now you've gone from "nonconstructive" to "just plain bloody-minded".


I have many problems with closures, and so do many others in this
newsgroup. My (and others') complaints are well-documented on this
newsgroup. I cannot feel any sympathy for you if you did not look to
gauge our reactions to basic

>>> * Allow subclassing an enum with the subclasses able to REMOVE (not
>>> add!) values.

>>
>> Very ugly.

>
> In your humble opinion.


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;
}

since SomeEnum$A, SomeEnum$B, and SomeEnum$C inherit SomeEnum.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-30-2008
Harold Yarmouth wrote:
>> If you have nothing pleasant or constructive to say, might I suggest
>> that you keep your mouth shut in the future?


Joshua Cranmer wrote:
> I'm sorry. I assumed you had been a denizen of this newsgroup for a
> while and therefore had seen my copious commentary of operator
> overloading in the past year or two (which has come up in at least three
> separate threads).


None of the nasty things Harold says or implies about you are true, Joshua.

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-30-2008
Hendrik Maryns wrote:
> But note that *the* big disadvantage with Jakarta Commons is no
> generics, although finally, there is an effort going on.


I lost a lot of respect for the Apache Commons projects when the commons-lang
project refused to fix the bug in their 'enums' implementation that relies on
a reference to the 'class' literal initializing the class itself.

This used to work prior to Java 5 due to a bug in the implementation of Java.
When Sun fixed the bug, commons-lang broke under that circumstance. The PTB
of the commons-lang project refuse to fix their bug.

WTF?

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-30-2008
Sorry about the accidental post - I fumble-fingered it.

Andreas Leitgeb wrote:
>> Yes, yes, yes! Not sure, if you got that idea yourself, or
>> from reading <(E-Mail Removed)>.
>> (in case google distorts it: "slrngfmc50.4jb.avl" is the part
>> before the "at")


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


This might or might not have occurred to you, "Harold", but others beside you
read this newsgroup. Some of them use GG. Andreas was being responsible for
that, and advising other readers how to decipher his post. He was not talking
only to you.

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-30-2008
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.

--
Lew
 
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