Java 7 features

[Piotr Kobzda]

Oliver Wong wrote :

Indeed there is.

If I have the following:

public class Foo
{
public static final int BAR = (new FooBar("foobar")).getIndex();
public static final int BAR_2 = (new FooBar("foobar2").getIndex();
}

If the constructor for FooBar("") is defined as throwing a checked
exception, how do you handle it?

Simply:

public class Foo
{
public static final int BAR;
public static final int BAR_2;
static {
try {
BAR = (new FooBar("foobar")).getIndex();
BAR_2 = (new FooBar("foobar2").getIndex();
} catch(Exception e) {
throw new ExceptionInInitializerError(e);
}
}
}

Note2: There are other constructs to attach the new FooBar to the class
Foo, but they are not relevant to this discussion...

They are relevant (at least the above solution is). Custom exception
handling is the only difference between the solution and your example
above (in both cases fields initializers' code is executed in a class
initializer).


piotr

 

[ldv]

A talked with the Jet people about this anomaly. They said the
Pentiums have such damaged lookahead logic they do very badly on jump
tables.

This problem and many others are specific to Pentium 4, not the entire
Pentium line. AFAIK, the current Intel chips are in fact successors of
Pentium 3.

LDV

 

[Patricia Shanahan]

I have found a bug in my benchmark. The random numbers
generated were often negative and thus prefered one branch.

Now, I have changed

final int random =( randomizer / 65536 )% 10;

to

final int random =(( randomizer / 65536 )& 0x7fffffff )% 10;

everywhere.

After this, the if-sequence is not faster then the switch
anymore, but both take the same time. This confirmes the text
quoted before, which claims that the switch was implemented by
if-sequences.

For the special case of a dense array of values to be
converted into other values, one might also use a look-up
table. I have tried this, and it is indeed much faster than
the switch.

I think for both an if-sequence and a table switch the time would be
dominated by the unpredicted branch. The table switch has a single
branch to a dynamically selected location, with each of the ten
locations equally probable. The if goes through a cascade of conditional
branches, most of which are taken on most executions.

I would not base any predictions about real programs on this. It is
relatively rare for all cases in a switch to have equal probability, and
for there to be zero correlation between branch history and branch
behavior. Hardware is unlikely to be optimized for that case.

Patricia

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Twisted schreef:

You can't snip the whole argument and handwave "I do not think it is
valid" and expect to be believed.

You’re right, sorry.

Either respond in detail and marshal
some evidence to support your POV, or forget about it.

I already indicated that I did not understand your argument. I do not
see any reason at all to introduce non-nullable variables etc., I do not
even see how it is related to checked exceptions.
Since I do not grasp your concerns, it is impossible for me to reply to
them.

If you have a
detailed proposal for how to make all the RuntimeExceptions checked
without driving Java programmers mad (or everyone just spalling
"throws RuntimeException" on every method), then by all means spell it
out.

Of course I do not have such a proposal. However, I just wanted to
point out that it isn’t impossible.

But pointing us to some Web site regarding some other programming
language entirely is a cop-out. We want to discuss these ideas here in
the newsgroup, not go off someplace else and read a monologue on the
subject where we can't reply with our own thoughts, and which isn't
even based on Java.
ACK.

P.S. whether it is doable with RuntimeException or not, I think it's
frankly impossible with Error. Those can literally pop up anywhere.
Any "new" can throw OOME, for instance, and therefore any method call
might, since it might have a "new" in it directly or by way of further
calls. Making those checked really would just force everyone to put an
explicit "throws Error" on every method. Right now, basically, a
"throws RuntimeException, Error" is implied on every method
declaration, and I think that's just fine...

Indeed. Maybe on second thought, I am all in favor of getting rid of
checked exceptions, since all exceptions should be handled _always
anyway_. Even OOME, be it that you do not do anything and just quit
(that is also a way of handling it). So basically, every function
should be put in a try catch block. But then, what is it for, if it is
always there? If you think this further, you might as well leave that
out and just attach to each method a block that describes what to do in
case of failure. That is basically what Eiffel does.

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

iD8DBQFGjQGWe+7xMGD3itQRAm0PAJ0blGQUhqdffvTjY0KMxDlnlzmoJwCfb5CM
8GKMr/1iUn1UzrlQ/Us3IL8=
=8XcG
-----END PGP SIGNATURE-----

 

[Wojtek]

Piotr Kobzda wrote :

Simply:

public class Foo
{
public static final int BAR;
public static final int BAR_2;
static {
try {
BAR = (new FooBar("foobar")).getIndex();
BAR_2 = (new FooBar("foobar2").getIndex();
} catch(Exception e) {
throw new ExceptionInInitializerError(e);
}
}
}

But does not the final keyword preclude this?

And I also get an error that BAR has not been initialized.

 

[Tom Hawtin]

Piotr Kobzda wrote :

But does not the final keyword preclude this?

Does the final keyword preclude:

class Fred {
private final int value;
public Fred(int value) {
this.value = value;
}
}

?

What is really annoying is that, for reasons I am not familiar with, you
cannot write Foo.BAR = 42;.

Tom Hawtin

 

[Piotr Kobzda]

But does not the final keyword preclude this?

As long as this follows the JLS rules for final fields (blank final in
this case) it doesn't.

See:
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#35962

And I also get an error that BAR has not been initialized.

I don't have it.

<sscce>
public class Foo
{
public static final int BAR;
public static final int BAR_2;
static {
try {
BAR = (new FooBar("foobar")).getIndex();
BAR_2 = (new FooBar("foobar2")).getIndex();
} catch(Exception e) {
throw new ExceptionInInitializerError(e);
}
}
}
class FooBar {
FooBar(String s) throws Exception {}
int getIndex() { return 0; }
}
</sscce>


piotr

 

[Piotr Kobzda]

What is really annoying is that, for reasons I am not familiar with, you
cannot write Foo.BAR = 42;.

The reason seams to be there:
http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.5.6.2

bullet 2.3:

"* Otherwise, if the class variable is declared final, then Q.Id denotes
the value of the class variable. The type of the expression Q.Id is the
declared type of the class variable after capture conversion (§5.1.10).
If Q.Id appears in a context that requires a variable and not a value,
then a compile-time error occurs."


piotr

 

[Wojtek]

Piotr Kobzda wrote :

As long as this follows the JLS rules for final fields (blank final in this
case) it doesn't.

See:
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#35962


I don't have it.

Eclipse gives the error.

 

[Roedy Green]

I think for both an if-sequence and a table switch the time would be
dominated by the unpredicted branch. The table switch has a single
branch to a dynamically selected location, with each of the ten
locations equally probable. The if goes through a cascade of conditional
branches, most of which are taken on most executions.

An IF chain would get a boost from smart hardware that noticed a
pattern in distribution, but in this case the branches are equally
probable, so that would NOT help the IF implementation. Yet for some
reason IF is STILL doing EQUALLY well!

Perhaps IF hardware can lookahead 10 steps or so?

 

[Stefan Ram]

I never liked the asymmetry of »x.multiply( y )«.
I'd prefer:
x * y -> new BigDecimalPair( x, y ).multiply()

So, by now, the reader should be able to estimate
which of the following two example lines I prefer:

vvvvvvvvvvvvv
(10..20).each { |i| puts i } // ruby
10.LoopTo(20) ( i => i.PrintLine() ); // C#
^^^^^^^^^^^^^

http://blog.bittercoder.com/PermaLink,guid,05fc0109-3215-410e-8009-447c1e74cacb.aspx

 

[Tom Hawtin]

So, by now, the reader should be able to estimate
which of the following two example lines I prefer:

vvvvvvvvvvvvv
(10..20).each { |i| puts i } // ruby
10.LoopTo(20) ( i => i.PrintLine() ); // C#

But a range is a sensible type of object. It's not just some old
2-tuple. I prefer not hard coding range constants.

I don't like the symmetry of new BigDecimalPair( x, y ).multiply(). I
much prefer new TwoBigDecimalsAndAnOpTriple(x, y, MULTIPLY).evaluate().
Or getting a bit mathematical new BigDecimalExpression(x, new
BigDecimalUnaryOperator(y, MULTIPLY)).

Tom Hawtin

 

[Stefan Ram]

I don't like the symmetry of new BigDecimalPair( x, y ).multiply(). I
much prefer new TwoBigDecimalsAndAnOpTriple(x, y, MULTIPLY).evaluate().
Or getting a bit mathematical new BigDecimalExpression(x, new
BigDecimalUnaryOperator(y, MULTIPLY)).

This might mean that

out.println()

would be written as

new PrintStreamAndAMethodName( out, PRINTLN ).evaluate()

It is more dynamic, because the operator or method name can be
chosen at run time, but this benefit might not always make up
for the additional overhead.

~~

One reason for my preferences of pair classes is as follows:

A large program can be maintained more easily, if for every
operation one knows where to find it. So whenever, one looks
for an operator on a pair of big decimals, it has to be in the
class BigDecimalPair. The location of the operator source code
can be determined by the types of its operands.

(Ignoring inheritance and assuming that the dispatch uses the
types of the operand expressions, not of the operand objects.)

 

[Andreas Leitgeb]

And another vote for checked exceptions from me.
[...]
In my experience (from dealing in the past with C++ exceptions) this is
one of the things Java currently has right; you can use static analysis
tools to find misuse of checked exceptions (e.g. catch Exception) and
they greatly reduce the number of unexpected thread or process deaths
post deployment.

Actually, I'd like java to change such, that I may also catch
exceptions that are *not* thrown inside the block! - Ok, it could
issue a warning, but shouldn't be an error.

Why?

try {
...
statement_that_can_throw_MyException(...)
...
} catch (MyException e) {
...
}

I would like to be allowed to temporarily //comment out the thrower
during development without having to also comment out the handler
block synchronously.

Btw., I don't like to use "if(0)" for commenting.

 

[Andreas Leitgeb]

I find this actually good in C++! it means, that I can program
a more-efficient version that in-place-modifies its left operand,
rather than create a temporary result-object and assign it to
the left operand in the end. Note, that C++'s assignment is
fundamentally different from Java's in that assignment is an
action of the object, not of it's reference.

What if I have a Matrix class that overloads the '*' operator and I want
to do the simplest scalar multiplication: 5 * m? (This is where C++
operator overloading gets really complicated.)

I must admit that I'm not aware of any troubles involved
in overriding such an operator (in C++). Even if overriding "*"
for int,Matrix really wasn't possible (haven't yet tried)
you could still reverse the order, since matrix-scalar
multiplication is usually commutative.

 

[Twisted]

I must admit that I'm not aware of any troubles involved
in overriding such an operator (in C++). Even if overriding "*"
for int,Matrix really wasn't possible (haven't yet tried)
you could still reverse the order, since matrix-scalar
multiplication is usually commutative.

What if the scalars are quaternions?

 

[Twisted]

I would like to be allowed to temporarily //comment out the thrower
during development without having to also comment out the handler
block synchronously.

Seconded. It should just be a warning, like other provably-unreachable
code.

 

[Andreas Leitgeb]

What if the scalars are quaternions?

Or anything else for that matter, like strings(*==concat), functionals,
etc... Then they are not "int"

And overloading an operator* for (Quaternion,QuaternionMatrix) has
not been claimed to be any problem ...

 

[~kurt]

Recently, I was looking around online and came across this (partial) list
of new Java 7 features. What I want to know is what support/disapproval
people have of these options:

How about complex numbers as a primitive type?

- Kurt

 

[Roedy Green]

How about complex numbers as a primitive type?

Circa 1999 Bill Joy told me that was high on his list. Though he was
hoping for a more generic way of doing it so you could handle similar
problems efficiently. That way you could have an array of Complex
but the objects would be lined up right after each other, rather than
scattered around RAM with an array of pointers to them.