Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

7.0 wishlist?

 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      11-04-2008
Mike Schilling <(E-Mail Removed)> wrote:
> Andreas Leitgeb wrote:
>> Mike Schilling <(E-Mail Removed)> wrote:
>>> void method(String s, int)

>> That is exactly what Harold proposed for Java.
>> My own opinion: not worth the trouble

>
> It's a fully compatible change (all existing code still works) and has no
> run-time consequences; to me, that means the bar for making the change is
> low. It would be unfortunate to make it the only syntax change in a
> release, since it forces changes to all compilers, debuggers, code
> analyzers, etc, but if it's only one of several changes, it would probably
> be the most minor one.


If the amount of trouble can be reduced, then it might be
worth the reduced amount of trouble

 
Reply With Quote
 
 
 
 
Mike Schilling
Guest
Posts: n/a
 
      11-04-2008
Andreas Leitgeb wrote:
> Mike Schilling <(E-Mail Removed)> wrote:
>> Andreas Leitgeb wrote:
>>> Mike Schilling <(E-Mail Removed)> wrote:
>>>> void method(String s, int)
>>> That is exactly what Harold proposed for Java.
>>> My own opinion: not worth the trouble

>>
>> It's a fully compatible change (all existing code still works) and
>> has no run-time consequences; to me, that means the bar for making
>> the change is low. It would be unfortunate to make it the only
>> syntax change in a release, since it forces changes to all
>> compilers, debuggers, code analyzers, etc, but if it's only one of
>> several changes, it would probably be the most minor one.

>
> If the amount of trouble can be reduced, then it might be
> worth the reduced amount of trouble


It doesn't have to be reduced, just mixed in with enough other trouble
that it appears insignificant

And that's not entirely silly. It happens sometimes that when I'm
fixing bugs I'll pick a few related "annoying but not urgent" ones and
fix them all at once, so that the cost of reminding myself exactly how
that part of the code works and running the unit tests gets amortized
over all of them.


 
Reply With Quote
 
 
 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      11-04-2008
Harold Yarmouth <(E-Mail Removed)> wrote:
> Andreas Leitgeb wrote:

[transparent class wrapping]
>> Compared with mine, you left out the class-equivalence part.

> I fully intended the wrap to test true with "instance of" the base, be
> castable to the base, and so forth. You want two-way equivalence,


You wanted castability from wrapper to base, I wanted equivalence.
Equivalence is always symmetric.

[nonnull-ness]
>> In that case we could use "*" also within generics, and only if
>> both a type-parameter is "*"ed (public V* get() ...) AND the type
>> parameter was "*"ed (List<Integer*>), then the return value would be
>> known as statically not-null.
>> All fine, except that I dislike the asterisk as marker.

> Got another (equally brief) preference?


I found some page that proposed "#" for it, and gave arguments against
doing it with annotatons. It also had some flaws in it, but parts of
it are quite reasonable. I'm talking of:
http://docs.google.com/View?docid=dfn5297z_2kjj2fk
The flaw is with overriding methods that change the null-allowedness.
e.g.:
class Base { void foo(Foo f) { ... } } // Base.foo allows null arg.
class Sub extends Base { void foo(#Foo f) { ... } } // Sub.foo doesn't.
Since the compiler doesn't know what instance is really stored in a
Base typed reference, it cannot do the right check for null, so it's
inevitable to still check for null inside Sub.foo(...)'s body.

>> Concurrency is a beast. Unless we had special idioms that resulted
>> in: getField...,dup,isnull?,ifyes:NPE,elseutField (pseudo-bytecode),
>> we'd indeed still need the cast.


> Nah, just put in the runtime check if it cannot be null without a
> concurrency bug, but might be with one.


That's just the situation at hand:
A (null-allowed) field that at some point happens to be not null
shall be copied into a non-null other field.

At no point in time do we want to risk the null to enter the target
field, because even if we get a NPE afterwards, unrelated code in
a second thread may see the null before the the null-check in this
thread sees it, and thus the goal of "knowing where it happened" would
not be met.

The only ways to get this really safe is to either copy it to a
local variable first, check that, and only on success copy it to
the target, or have the principially same thing happening
on the stack at jvm-level, as I mentioned it above.

[unused parameter names]
> Rare? You obviously don't write a lot of action listeners or exception
> handlers, unless the former are shared among many components and the
> latter are always doing an e.printStackTrace().

Where I get into such situations, I either spend a one-letter name,
or some acronym, like "npe" when catching a NullPointerException,
no matter if I use it or not. I find eclipse's warning about
unused parameters goofy, and would turn it off anyway, if I ever
used eclipse.

Enough for today.
While deleting the rest of the quotes, I saw that I didn't have much to
say about them anyway.
 
Reply With Quote
 
Hendrik Maryns
Guest
Posts: n/a
 
      11-04-2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harold Yarmouth schreef:
> Hendrik Maryns wrote:
>> Harold Yarmouth schreef:
>>> Hendrik Maryns wrote:

> There are far more diplomatic ways to express a difference of opinion,
> ones that do not impugn publicly the competence or intelligence of
> whoever you are disagreeing with.


ACK. It is difficult to stay polite if you don’t see the person on the
other side.

> Why are you jumping into what's essentially become a personal argument
> between me and Joshua Cranmer, anyway? It has nothing whatsoever to do
> with Java. Really you ought to just let it drop.


You might notice my name up there.

>> your argument about a duplicate just doesn’t make sense.

>
> Your failure to understand it is not the same thing as me writing
> nonsense, and I'll thank you to stop being insulting towards me in public.


Sorry, see above. OTOH, I think you could be a little less sensible in
this respect. I, for one, would not feel insulted if someone said an
argument of mine doesn’t make sense, provided he provides some arguments.

>> Right, so indeed you want literals to be interned. You didn’t write
>> that in your original proposal, hence the confusion. In the current
>> setting, your suggested syntax would just be syntactic sugar

>
> Even that, by itself, is not useless.
>
> If your dislike of this proposal is out of concern that it will be
> abused and arrays that *should* be named and placed in the constant
> declarations won't be, please keep in mind that your argument against it
> is then also an argument in favor of banning integer or string literals
> in method calls, among other things.


I didn’t say I dislike this proposal, I explicitly said I do not know
enough of the consequences of this to comment on it and haven’t felt a
strong need for it, yet. But that was after the misunderstanding was
cleared up.

>>>>>> There's also this for the last one:
>>>>>> new HashMap() {{
>>>>>> this.put("key1", "value1");
>>>>>> this.put("key2", "value2");
>>>>>> }};
>>> It works, but it's crude and has crummy and verbose syntax.

>>
>> Oh, I totally agree with you on that one. I would simply write
>> Map<Kye, Valeu> vars = new HashMap<Kye, Valeu>();
>> vars.put(kye1, valeu1);
>> vars.put(kye2, valeu2);

>
> That's just going back to square 1.


Yup, I’m satisfied with square 1 in this respect.

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

iEYEARECAAYFAkkQVsYACgkQBGFP0CTku6OYmwCgjL/yhs3KbZ9KwVvnuS/Vu+CX
kA4AoItMlelfZCixD4TokZE1AMYI6nhO
=Fot/
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Hendrik Maryns
Guest
Posts: n/a
 
      11-04-2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harold Yarmouth schreef:
> Joshua Cranmer wrote:
>> Harold Yarmouth wrote:
>>> ~= perhaps, for equals()?

>>
>> o_O ... that makes no sense

>
> To you, perhaps.


Did you think of the ~ as in ≅? Then it does make sense, but ~ is often
used for negation, so also confusing. Whatever, really.

>> 2. A "neat" way to create pair objects.

>
> Pair literals could be added, surely.


You are implying interning again. I do not see a direct correspondence
between literals and interning. In fact, I see no reason why [a,b]
would not create a new pair in the background each time. It is only a
question how much trouble the jvm implementors want to go through.

'z' and 15 are also literals, but I doubt there is only one version of
them around in memory, just to illustrate the difference between
interning and literals.

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

iEYEARECAAYFAkkQfU8ACgkQBGFP0CTku6OSCQCeJc1+3GFk3/IGLhIxkCLwqKaV
NyUAoIIfHkuyde5Bk/NGYD3wllUUn3tb
=FKG9
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Hendrik Maryns
Guest
Posts: n/a
 
      11-04-2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harold Yarmouth schreef:
> Hendrik Maryns wrote:
>> Harold Yarmouth schreef:
>>> Hendrik Maryns wrote:
>>>> I think you don’t understand.
>>> I think I'm beginning to find unprovoked personal insults quite
>>> tiresome. If Emily Post ever stumbled across this newsgroup, she'd go
>>> white as a sheet!

>>
>> Since when is pointing out a misunderstanding an insult?

>
> Pointing out a misunderstanding, in and of itself, is not an insult.
>
> Publicly accusing a specific person of stupidity, on the other hand, is
> an insult.
>
> This is a forum for discussing Java programming, not for assigning blame
> and arguing over who is at fault.
>
> But now that you've raised the issue of blame and now that my
> intelligence and competence have been publicly called into question by you:
>
> If there was a misunderstanding, and if it was a particular person's
> fault, then it was your fault, not mine.


When did I write ‘blame’? When did I say you are at fault?

>>>>> 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.
>>> No; the needed gamut of collection classes should be (and mostly already
>>> is) in java.util.

>>
>> I agree with that, but it doesn’t make the statement less true that, if
>> java.util (or whatever other package provided by Sun) does not contain
>> the wanted behavior, it is smart to go look for libraries that do
>> provide it.

>
> How do you find such? For things like adding .xpm image support you
> search for ".xpm image support java" or ".xpm image library java"; for
> esoteric math stuff "math library java"; etc.; but searching for
> collections will lead directly to Sun's java.util API docs and related
> content, and will lead to little else.


Finding Jakarta Commons Collections might be difficult, but my point was
simply that it is worth looking for a library. If you don’t find one,
that’s unfortunate, but no harm is done.

>> Other people probably have thought about that problem
>> before, and probably longer than you have (yet).

>
> I don't know if this was intended as an insult, or just as a silly
> suggestion that nobody be allowed to suggest or ask for anything without
> first getting a comp sci Ph.D. or something.


It was not intended as an insult. In fact, I have never in my life
intended anything as an insult. What I tried to point out is that it is
wiser to try to use the wisdom of other people, instead of doing
everything yourself.

Did I say not to suggest? Did I say not to ask? If so, I didn’t mean to.

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

iEYEARECAAYFAkkQfusACgkQBGFP0CTku6N7zQCgoQ7OfeBHpW CkglT1ekcO9kJb
c8wAnRjqbA0rlilw+cxjFTMVu02jOu9q
=8Bbe
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Hendrik Maryns
Guest
Posts: n/a
 
      11-04-2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harold Yarmouth schreef:
> Hendrik Maryns wrote:
>> Harold Yarmouth schreef:
>>> Hendrik Maryns wrote:
>>>> 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 meant to mean "this class cannot be instantiated".

>>
>> Since we don’t agree here, it seems like arguments are needed. I’d
>> start with http://en.wikipedia.org/wiki/Abstract_type and claim that it
>> favors my view of the matter: an abstract class is supposed to be
>> subclassed.

>
> The only thing relevant here is the Java specification, and what it says
> about abstract in a class declaration is that it makes the class
> uninstantiable, also allowing it to have abstract methods.
>
>>> I can't think
>>> of anything in Java much more "abstract" (in the English sense) than a
>>> utilities class with no instances.

>>
>> Fine, but the keyword has its specific semantic meaning and as is often
>> the case in computer languages, these do not always relate to the
>> meaning of the word in the real world.

>
> The meaning of the word in the JLS, on a class declaration, is
> "uninstantiable and permitted to have abstract methods". And nothing
> *else* in the language presently means "uninstantiable". (Having a
> private constructor and no non-private ones has the effect, but does not
> declare it as a first-class intention.)
>
> Perhaps there should be something else in the language that can be used
> to specify "uninstantiable, but not an abstract type in the Wikipedia
> sense", but presently there is none, so I suggested being able to fully
> use what's already there.
>
> If you'd prefer to add a new reserved word and maybe break lots of old
> code, though, you go right on ahead and suggest it.


I wasn’t aware of that, thanks for explaining.

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

iEYEARECAAYFAkkQfzQACgkQBGFP0CTku6OVnACdGg+w3lV/yiIVOVUBAOLoEyWr
4zgAn11tJEz0YAgeOxYtz/3QpSHQRZ0L
=uX7v
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Hendrik Maryns
Guest
Posts: n/a
 
      11-04-2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Leitgeb schreef:

[about non-nullability]

> I found some page that proposed "#" for it, and gave arguments against
> doing it with annotatons. It also had some flaws in it, but parts of
> it are quite reasonable. I'm talking of:
> http://docs.google.com/View?docid=dfn5297z_2kjj2fk
> The flaw is with overriding methods that change the null-allowedness.
> e.g.:
> class Base { void foo(Foo f) { ... } } // Base.foo allows null arg.
> class Sub extends Base { void foo(#Foo f) { ... } } // Sub.foo doesn't.
> Since the compiler doesn't know what instance is really stored in a
> Base typed reference, it cannot do the right check for null, so it's
> inevitable to still check for null inside Sub.foo(...)'s body.


Isn’t this breaking Base.foo’s contract? (You know, Liskov.)

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

iEYEARECAAYFAkkQgLEACgkQBGFP0CTku6N56QCggaAEjfb1UH Rg8PhpSx9P7Oiv
w5YAniPXWu8ztKxcbyLaNCb+nVcBd5T6
=GULd
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      11-04-2008
Hendrik Maryns <(E-Mail Removed)> wrote:
> Andreas Leitgeb schreef:
> [about non-nullability]
>> http://docs.google.com/View?docid=dfn5297z_2kjj2fk
>> The flaw is with overriding methods that change the null-allowedness.
>> e.g.:
>> class Base { void foo(Foo f) { ... } } // Base.foo allows null arg.
>> class Sub extends Base { void foo(#Foo f) { ... } } // Sub.foo doesn't.


It was not really a flaw, since the mentioned classes (ConcurrentHashMap
and HashMap) are just siblings both derived from AbstractMap. So, finally,
if AbstractMap (and Map) declared it's put(...) to accept only non-null
values, then HashMap and TreeMap could both broaden the domain (i.e. allow
also null) and ConcurrentHashMap leave it as is. All that without breaking
any contracts. Otoh., declaring Map as taking no nulls isn't any likely
to happen...

> Isn’t this breaking Base.foo’s contract? (You know, Liskov.)


Yes, it would be this way. It would not be the other way (if
Base.foo took only non-null and Sub.foo accepted null as well).

 
Reply With Quote
 
Roger Lindsj
Guest
Posts: n/a
 
      11-04-2008
Harold Yarmouth wrote:
> Andreas Leitgeb wrote:
>> 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.

>
> Enum values having numeric values that form a continuous range starting
> with 0 is overrated anyway. I rarely if ever use this. I'd suggest not
> only letting subset-enums violate this, but letting ordinary enums do so
> at the coder's behest, i.e. let them override value to return whatever:


I have used it to get a next() and prev() functionality of enums (think
I used something similar in Pascal or Turbo Pascal). So for me having a
clearly defined value has it's "value"

--
Roger Lindsj
 
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