Java 7 features
Joshua Cranmer
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:
@ Closures
@ Strings in switch statements
@ Operator overloading for BigDecimal
@ Language-level XML support
@ Reified generics
@ Superpackages
@ Removing checked exceptions
Personally, I am in support of items 2 and 5; indifferent on 3, 4, and 6;
and against items 1 and 7.
Tom Hawtin
>
> @ Closures
But we already have (minimal) closures. I think it would be much more
sensible to improve what we already have, rather than to duplicate. It's
probably unlikely to get in before Java 1.8 anyway.
> @ Strings in switch statements
Not too fussed. It'll make switches on strings clearer, but perhaps will
encourage poor code.
> @ Operator overloading for BigDecimal
BigDecimal and BigInteger are hideous to use at the moment. The overflow
semantics of primitive integers are not something that I think should be
in a high level language. I'd prefer general operator overloading of
sensible operators.
> @ Language-level XML support
Evil and unnecessary. A lot like much of XML.
> @ Reified generics
This could have made sense in 1.5. But I don't think this is really on
given the situation we have got ourselves into.
> @ Superpackages
Good. I guess packages provide what is necessary from superpackages, but
we tend to write libraries and applications in more than one package.
> @ Removing checked exceptions
I like static type checking.
Tom Hawtin
Arne Vajhøj
for: 2, 3, 5
against: 1, 4, 7
neutral: 6
Arne
Twisted
> (Yes, I realize that I am about to potentially unleash strong opinions.)
>
> 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:
>
> @ Closures
Depends. Syntactic sugar to make anonymous inner classes easier to
use: for. Dropping the "final" requirement on referenced local
variables: for. A simple anonymous lambda function ability that
results in first class objects with the ability to compute and return
values: for (this could be had in the form of an appropriate generic
interface and easier anonymous inner classes). Anything really ugly or
hairy: against. Otherwise neutral.
> @ Strings in switch statements
I'd really like to see either switch statements deprecated, switch
statements made enum-only, or switch statements made into syntactic
sugar for ANY lengthy if-elseif-elseif-elseif-else chains.
> @ Operator overloading for BigDecimal
Either none or for any custom class, please, or better yet, require
declaring the operators in an interface, and then binary operators
work when both argument types implement a common interface specifying
that operator, and are type errors otherwise.
> @ Language-level XML support
Bleh. Either skip it or put language-level metalanguage capabilities
in, where you get a construct to declare parsers that use a context-
free-grammar in bison format to define a translation from some syntax
to Java, and you can then use a construct like "import MyLanguage
{ code in my language }" which is translated into Java if the compiler
can resolve the MyLanguage parser definition (a new package level
thing to go with classes, interfaces, and enums). This simple thing
adds no new keywords (by overloading "import") and lets you use almost
anything in your language (except }, and it should treat Java comments
as comments). No doubt there'd be a bazillion XML parser definitions
out there before you could blink anyway.
> @ Reified generics
That depends on how they work. Run-time availability of type parameter
info? If you can make it fly without being too ugly or baroque.
Numeric parameters? That might be nice for fixed-size-vector classes
and things of that nature.
> @ Superpackages
Whatever that means. If it means treating package names as a proper
hierarchy, so that (as is already implied, but untrue)
com.mysite.mystuff.foo.Bar automatically sees com.mysite.mystuff.Quux
and you can tidily import Bar into Quux as "import foo.Bar" or
"import .foo.Bar" ... sure.
> @ Removing checked exceptions
Are they out of their cotton-picking MINDS?!
P.S. a URL with more in depth explanations of what exactly is being
proposed would be handy about now.
Hendrik Maryns
Hash: SHA1
Joshua Cranmer schreef:
> (Yes, I realize that I am about to potentially unleash strong opinions.)
>
> 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:
>
> @ Closures
> @ Strings in switch statements
> @ Operator overloading for BigDecimal
> @ Language-level XML support
> @ Reified generics
> @ Superpackages
> @ Removing checked exceptions
The only thing that I definitely support is the last one, but probably
in the unusual way: indeed, get rid of checked exceptions, by making
*all* exceptions checked.
For the skeptic: it can be done, see how Eiffel handles it.
Oh, and who the hell needs switch statements?
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
iD8DBQFGihdue+7xMGD3itQRAkToAJwKeYQOXChNjF8ReCbZPAmG2q7JDgCdHjjB
IvSmnQUS/PID5fx4pTvlIEc=
=gwOO
-----END PGP SIGNATURE-----
julien.r...@gmail.com
Small comment...
On Jul 3, 5:04 am, Twisted <twisted...@gmail.com> wrote:
> On Jul 2, 5:27 pm, Joshua Cranmer <Pidgeo...@verizon.net> wrote:
> > @ Strings in switch statements
>
> I'd really like to see either switch statements deprecated, switch
> statements made enum-only, or switch statements made into syntactic
> sugar for ANY lengthy if-elseif-elseif-elseif-else chains.
I used switch statements much more in C++ than now in Java. Mainly
because, whereas Java has introduced a discrepancy between == and
equals(), switch only applies to ==.
What I would suggest is a new switch, so that we have "switch" and
"switch-equals"
switch: runs through all cases comparing with the operator "==". May
accept null, and probably useless for strings.
"switch (x) {case y:..." should be exactly the same behavior as "if (x
== y)..."
(I *think* that's the one we have... just goes to show how much I use
it!)
switch-equals:
uses "equals()" to test each case. Requires passing an object (or uses
auto-boxing?).
It could not accept null pointers, even though I would favor:
"switch (x) {case y:" should be exactly the same behavior as
"y.equals(x)"
so that x may be null
If ever some y is null, throw NullPointerException of course. :-)
and if x is null, of course it switches to default.
Problem is: what if there's y1 and y2 and both are equal? Simply
precise that only the first match will be acted upon.
This may be ugly, but I agree that:
* switch, as is it, is not very consistent with Java thinking, because
of the "equals" method
* because of this, it is not very much used (at least that's what
people around here are saying)
* making special cases for types is probably to be avoided (as much as
possible of course).
All this said with the ignorance of a non-expert programmer... :-)
JR
Roedy Green
<Pidg...@verizon.net> wrote, quoted or indirectly quoted someone who
said :
>@ Closures
Not keen. I think this will needlessly make code hard to understand by
the general programmer.
>@ Strings in switch statements
Not as big as deal as it once was now there are enums. The feature
will encourage inefficient code. I would like instead RANGES of ints
and enums that generate better code and code easier to maintain than
you would do manually. This is a relatively trivial extension,
requiring no JVM change. See
http://mindprod.com/projects/caserange.html for what I a would like.
>@ Operator overloading for BigDecimal
fine. This can probably be done without a JVM change.
>@ Language-level XML support
I detest XML. So oppose this on general principles. I want XML to
die. This will just encourage it. see
http://mindprod.com/jgloss/xml.html
for my reasons for wanting to stamp out XML. I have the same disgust
for XML I have for grossly overweight gluttons and people enjoy
deliberate waste. Perhaps if it is done in a representation
independent way, XML can quietly be replaced without anyone noticing.
>@ Reified generics
I don't know what that means. Reify means to regard or treat (an
abstraction) as if it had concrete or material existence. Does this
mean tossing out type erasure? Generics are an embarrassment to the
language. I personally would like to start from scratch and see if
they can be made 10 time times simpler and wart-free.
>@ Superpackages
Probably just paying attention to the dots in package names. For ant
bundling it would be nice to just have to specify one name to grab
everything related.
>@ Removing checked exceptions
NO. That will just lead to sloppy code. Java is not PHP.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Roedy Green
<hendrik...@despammed.com> wrote, quoted or indirectly quoted
someone who said :
>
>Oh, and who the hell needs switch statements?
I use them all the time, nearly always with enums.
There are three ways of doing a computation. You can write a switch to
collect the 25 enums in three groups. This is much easier code that
calling a method in each enum. You can see the big picture. It is
easier to maintain and proofread.
See http://mindprod.com/projects/scid.html
for my proposal to have your cake and eat it too -- view code either
way.
The other place I use them is in writing finite state automata. One
nice feature of Java is if you leave out the default, it will warn you
if you have failed to mention one of the possibilities as a case
label.
tjmadd...@gmail.com
>
> P.S. a URL with more in depth explanations of what exactly is being
> proposed would be handy about now.
Here is an unofficial list, with links to discussions:
http://tech.puredanger.com/java7
Tim
timjowers
FWIW:
> @ Closures
Don't care. Have no problem passing classes and referencing needed
methods.
> @ Strings in switch statements
Don't care. I can type fairly fast. I kinda agree with the other posts
that an OO language should handle constructs in an OO way rather than
implementing special cases.
> @ Operator overloading for BigDecimal
Yes. Lack of operator overloading is just irritating to anyone who
used this heavily elsewhere. Operator overloading makes for much more
readable code.
> @ Language-level XML support
Don't care. Sounds like an unholy mess.
> @ Reified generics
Also don't know what this is/Don't care. If my bugs are due to type
casting of array elements then I have bigger problems than the version
of my programming language.
> @ Superpackages
Don't know. Would have liked for the CLASSPATH problem to never have
been created. It is the same as the lib/DLL hell and include path
problems of yesteryear. If Superpackages fixes that then yes. I
haven't studied but guess it is like Maven with net-based JAR linking.
> @ Removing checked exceptions
No because it sounds like a pain to change code and coding style.
One thing I would like to see is very tight integration with Linux.
With Linux being Open Source then Sun could feasibly write a kernel
module and maybe speed up the JVM on Linux I would guess.
I also think some more focus needs to be made on cross-JVM versions
and cross-version compiles. Some 80% of the Java code base runs in
Java 1.4 from what I heard at a JUG presentation. I think the big
challenge for Java is to get people/companies to move forward.
I'm very glad Sun is continuing to innovate.
Oliver Wong
"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
news:Java-7-200...@ram.dialup.fu-berlin.de...
>
> Also, consider:
>
> if( x instanceof A ){ A a =( A )x; ... }
> else if( x instanceof B ){ B a =( B )x; ... }
> else if( x instanceof C ){ C a =( C )x; ... }
>
> Forget for a moment that »instanceof« is a code smell.
> Sometimes it's needed.
>
> This could be written as
>
> if( x instanceof A ){ ... }
> else if( x instanceof B ){ ... }
> else if( x instanceof C ){ ... }
>
> if the compiler would keep track of the fact that x
> in the first block is now known to have the type of A,
> so that no further cast is required. (At least for
> an identifier »x« with »final« this should hold.)
>
I don't think this change is doable while remaining backwards
compatible. If methods are called on x and those methods are overloaded
and overridden, for example, this change would change which methods
actually gets called at runtime.
- Oliver
Oliver Wong
<julien.r...@gmail.com> wrote in message
news:1183462807.0...@w5g2000hsg.googlegroups.com...
>
> I used switch statements much more in C++ than now in Java. Mainly
> because, whereas Java has introduced a discrepancy between == and
> equals(), switch only applies to ==.
>
> What I would suggest is a new switch, so that we have "switch" and
> "switch-equals"
>
> switch: runs through all cases comparing with the operator "==". May
> accept null, and probably useless for strings.
> "switch (x) {case y:..." should be exactly the same behavior as "if (x
> == y)..."
> (I *think* that's the one we have... just goes to show how much I use
> it!)
Yes, I think that's an accurate mental model of how the switch
statement works
>
> switch-equals:
> uses "equals()" to test each case. Requires passing an object (or uses
> auto-boxing?).
> It could not accept null pointers, even though I would favor:
> "switch (x) {case y:" should be exactly the same behavior as
> "y.equals(x)"
> so that x may be null
> If ever some y is null, throw NullPointerException of course. :-)
> and if x is null, of course it switches to default.
How about adding a new case statement for nulls, and leaving default
to their original semantics?
switchequals (x) {
case y:
doThis();
break;
case z:
doThat();
break;
null:
doSomethingElse();
break;
default:
giveUp();
break;
}
is syntatic sugar for:
if (null == x) {
doSomethingElse();
} else if (y.equals(x)) {
doThis();
} else if (z.equals(x)) {
doThat();
} else {
giveUp();
}
and
switchequals (x) {
case y:
doThis();
break;
case z:
doThat();
break;
default:
giveUp();
break;
}
is syntatic sugar for:
if (null == x) {
giveUp();
} else if (y.equals(x)) {
doThis();
} else if (z.equals(x)) {
doThat();
} else {
giveUp();
}
Note that the compiler was smart enough to do whatever was necessary to
avoid NullPointerException.
While we're at it, how about changing the switch statement so that
statements after a case-label MUST end in either "break;" or
"fallthrough;" (or "continue;", if you want to avoid creating a new
keyword). So the following would no longer be legal code:
switch(x) {
case 1: //fallthrough
case 2:
doSomething();
}
and instead would need to be written:
switch(x) {
case 1:
continue;
case 2:
doSomething;
break;
}
>
> Problem is: what if there's y1 and y2 and both are equal? Simply
> precise that only the first match will be acted upon.
Agreed, as I think this parallels how switch currently works.
>
> This may be ugly, but I agree that:
> * switch, as is it, is not very consistent with Java thinking, because
> of the "equals" method
Note that switch statements refuse to work on anything except integers
(maybe longs?) and enums. Specifically, they don't work on objects, so the
"equals" method doesn't even come up as an issue yet.
- Oliver
Oliver Wong
"Joshua Cranmer" <Pidg...@verizon.net> wrote in message
news:U4eii.1525$Pv2.1459@trnddc03...
> (Yes, I realize that I am about to potentially unleash strong opinions.)
>
> 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:
>
> @ Closures
I'm sort of dreading this change, because it means once Java 7's out,
I will no longer consider myself a competent Java programmer. On the other
hand, might be a good opportunity to finally learn what closures are all
about.
> @ Strings in switch statements
Fine with me. Strings are already getting special VIP treatment in
Java as it is. Might be worth considering extending this to work with all
objects, as laid out in a post downthread about "switch-equals".
> @ Operator overloading for BigDecimal
I thought "No Operator Overloading" was an argument for favoring Java
over C++. The purist in me is already annoyed with the + operator being
overloaded for Strings. This seems like a step in the wrong direction.
> @ Language-level XML support
> @ Reified generics
> @ Superpackages
I'm ignorant and/or apathetic about the above.
> @ Removing checked exceptions
I like checked exceptions. I'm part of the crowd that is willing to do
more typing in exchanged for less buggy programs.
>
> Personally, I am in support of items 2 and 5; indifferent on 3, 4, and
> 6;
> and against items 1 and 7.
Would have been nice if you had numbered the items. =P
- Oliver
Bjorn Borud
|
| >@ Closures
| Not keen. I think this will needlessly make code hard to understand by
| the general programmer.
it is one of those things that are very fashionable now and fashions
are not necessarily dictated by what is actually a good idea. I have
seen some really unwieldly code written by people who have a raging
closure fetish -- using them everywhere and for everything. it may be
something you can get used to, but to me, the over-use just makes the
code hard to read and I can't really see the benefit -- other than
giving you the warm feeling of being buzzword compliant and
fashionable
sure, for some things closures are nice, but I only have use for them
occasionally. for the most part I think this is something people who
give lots of presentations at conferences really like and that it'll
eventually pass.
| >@ Language-level XML support
| I detest XML. So oppose this on general principles. I want XML to
| die. This will just encourage it. see
| http://mindprod.com/jgloss/xml.html
the theme appears to be "bloat". which I'd say is a valid reason to
dislike XML, but in many cases, I can live with a bit of bloat. there
are other issues that are far more troubling.
| for my reasons for wanting to stamp out XML. I have the same disgust
| for XML I have for grossly overweight gluttons and people enjoy
| deliberate waste. Perhaps if it is done in a representation
| independent way, XML can quietly be replaced without anyone
| noticing.
I am somewhat torn on this issue. back when I discovered SGML, I was
very enthusiastic. then when I actually read Goldfarb's book and made
an effort to understand SGML I realized that SGML was pretty pointless
(for a number of reasons which I will not bore you with, but if you
buy me enough beers and insist, I'll give you a long rant using really
colorful language).
then XML came around and I became a bit optimistic again. for a short
while. until I came to the conclusion that XML too was too
complicated for implementors to implement right, so you end up with
endless fiddling to get various implementations to actually talk to
one other.
then there were the various APIs and in the name of all things bright
and shiny, what were the people who made the DOM API thinking of!?
not to mention the people who decided it would be a good idea to turn
the thing into a standard!? someone should get their branding iron
out and make sure these people are flagged as dangerous. (this is as
kindly as I can put it)
of course, eventually there was JDOM -- which wasn't too bad all
things considered. still a bit fiddly, but a big step forward if you
do need to consume or produce XML.
as for the invention and use of "simple" or custom storage formats,
XML does remove some risk of people inventing really, *really* stupid
formats. I did work on a project some years ago where the collective
aversion to XML among the developers led to the decision that we'd
invent our own format -- so someone did. unfortunately he ended up
with something so terrible XML would have been heavenly compared to
it.
in that project I would actually have preferred XML as a way to
serialize structured data.
but then you have the XML-manicas that the Java world is so full of.
the sort of people who think that expressing things in XML rather than
Java code is better. as a friend of mine put it "oh, it was simple
enough to set up -- it just needed a few thousand lines of XML
configuration for the library to work".
the problem isn't really XML as much as it is the idiots it seems to
attract. from all directions.
-Bjørn
David Gourley
>>@ Removing checked exceptions
>
>
> I like checked exceptions. I'm part of the crowd that is willing to do
> more typing in exchanged for less buggy programs.
>
>
And another vote for checked exceptions from me. It would be
interesting to know what types of programs the folks who don't like
typed exceptions write (client software vs prototype/modelling SW vs
software with high availability requirements etc.)
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.
Dave
Roedy Green
<ow...@castortech.com> wrote, quoted or indirectly quoted someone who
said :
>
> Yes, I think that's an accurate mental model of how the switch
>statement works
There are two JVM instructions to implement a switch. Java's N-way
branch. In the JVM there are two different ways of implementing a
switch, tableswitch and lookupswitch. The efficient tableSwitch is a
jump table used when the switch values are reasonably dense e.g.
numbered 0..N. The less efficient lookupSwitch is a binary search used
when the switch values all all over the map. It thus pays to keep your
switch values dense.
Twisted
> switch: runs through all cases comparing with the operator "==". May
> accept null, and probably useless for strings.
Interning the strings makes them viable here.
> switch-equals:
> uses "equals()" to test each case. Requires passing an object (or uses
> auto-boxing?).
> It could not accept null pointers, even though I would favor:
> "switch (x) {case y:" should be exactly the same behavior as
> "y.equals(x)"
> so that x may be null
> If ever some y is null, throw NullPointerException of course. :-)
> and if x is null, of course it switches to default.
Why not allow null anywhere? Null is unequal to anything but null,
unless some object's ".equals(null)" returns true for whatever reason.
My own recommendation is to make switch use == on primitive
types, .equals on reference types, and give a warning when floats or
doubles are compared.
switch (primitive) {
case x:
...1
case y:
...2
break;
default:
...3
}
is made syntactic sugar for
if (x == primitive) {
...1
...2
} else if (y == primitive) {
...2
} else {
...3
}
for instance.
With a nonprimitive, you get
switch (object) {
case x:
...1
break;
case null:
...2
break;
default:
...3
}
turning into
if (object == null) {
...2
} else if (object.equals(x)) {
...1
} else {
...3
}
say. (Always the test for == null occurring first, with either the
appropriate case block or the default block's code, followed by any
others.)
But I've also got a good suggestion for any operator overloading.
Firstly, binary operators between reference types are allowed if both
compile-time types have a common superclass or implement a common
interface that specifies the corresponding method (including if the
compile-time types of both sides are equal and this type specifies the
appropriate method).
Secondly, operators are then just syntactic sugar as follows:
-x -> x.negate()
x + y -> x.add(y)
x - y -> x.subtract(y)
x * y -> x.multiply(y)
x / y -> x.divide(y)
x += y -> x = x.add(y)
++x -> x = x.increment() (and add this method to BigFoo; it returns a
new instance, representing a value one higher)
x++ -> (t = x, x = x.increment(), t)
--x and x-- analogously with a decrement() method
x ~= y -> x.equals(y) (a whole new operator; if ~= allowed for
primitive types it behaves the same as == for these)
!x (maybe allow as shorthand for x == null)
(various bitwise operators should correspond to their BigInteger
methods)
A key thing is that the implied method is always invoked on the left-
hand operand, with the right-hand operand (if any) as method argument.
This means that operators would be polymorphic only on the first
argument. Using double-dispatching or other patterns when implementing
your add, subtract, multiply, etc. methods in your own class hierarchy
would be able to give the benefits of bilateral polymorphism, of
course.
It would be desirable to be able to set a thread-local MathContext for
BigDecimal calculations and scope it somehow. I'd suggest a more
general "environment" or "context" mechanism built on a (hopefully
speeded-up!) threadlocal mechanism, whereby you can use code like
do switch (threadlocal: expression) { ... stuff ... }
(which overloads, unambiguously, existing keywords) to:
* Save the current value of the thread local somewhere
* Change it to "expression".
* Stuff
* Restore the old value of the thread local
It would be syntactic sugar for:
Object t3dsfgr838 = someThreadLocal.get();
someThreadLocal.set(expression);
try {
stuff
} finally {
someThreadLocal.set(t3dsfgr838);
}
where the temporary's name is guaranteed not to otherwise exist in
this scope.
There should then of course be built-in thread locals for some stuff
(such as math context to use for the forms of BigDecimal methods that
don't take an explicit one, and which overloaded + and the like would
use). Switching on a particular math context for a block of
calculations is then easy and natural:
do switch (Math.mathContext: myMathContext) {
someBigDecimal = someOther + yetAnother;
someBigDecimal *= 4; // Should accept mixed primitive/reference
// types IF the reference type has a valueOf(foo) method
// matching the primitive to use for promotion!
someMoreCalculations();
}
And of course ThreadLocal should be made a) faster to access (at least
to just read) and b) generic (so with a ThreadLocal<String>, you would
not have to cast theThreadLocal.get() to String, etc.; why was this
done promptly for WeakReference et. al. but not ThreadLocal? Arrrgh!)
Twisted
wrote:
> > @ Removing checked exceptions
>
> The only thing that I definitely support is the last one, but probably
> in the unusual way: indeed, get rid of checked exceptions, by making
> *all* exceptions checked.
> For the skeptic: it can be done, see how Eiffel handles it.
Are you out of your cotton-picking MIND?! I don't want to have to
declare every method as "throws RuntimeException" just because just
about everything might throw NPE and any of several other assorted
bounds, arithmetic, etc. exceptions. And if you want Error declared
too, just forgeddaboudit.
You'd have to massively redesign the language to make this have any
beneficial effect, instead of people just slapping "throws
RuntimeException" on everything. For starters, you'd have to have
fields, parameters, and locals that could be null or could not be, say
with
String foo = whatever;
String? bar;
meaning foo is a String, and bar may be a String or null, to make this
at all workable. A lot of code that would generate NPE will simply not
compile without explicitly handling the possibility of a null then,
but it also means they'd have to rewrite the whole standard library(!)
and everyone would have to rewrite their legacy code(!!) ... if they'd
done this from the beginning it would have been a good idea, but
changing it now would trigger chaos that'd make the last-minute
scrambling to fix Y2K bugs look like a Sunday picnic. Note that non-
nullable fields would be required to be explicitly initialized or else
assigned in every constructor, whether directly or by constructor
chaining. The example above explicitly initializes the String foo. A
local variable would have to be assigned immediately on being declared
if it could not be null, e.g. String foo = whatever; but never String
foo. That alone would break nearly all code. A more minor alternative
is:
String! foo = whatever;
String bar;
Again bar is the one that can be null, but all legacy code works. But
you wouldn't see a decrease in implicitly NPE-capable code until the
new !-declarations became widespread in currently-used codebases, and
only then might having to declare this exception be anything but a
massive PITA. On the flip side, the ? version above would be a massive
PITA whether or not NPE became a checked exception at the same time...
And of course there's still the potential for the NPE to crop up at
runtime. The String!/String or String/String? distinction would
probably only exist at compile time, like generic type parameters do
now. Even if it did exist at run time, it would have to do something
if an attempt was made to assign null to the wrong reference, and the
obvious thing is to eagerly throw the NPE that would otherwise happen
anyway but happen further from the location of the buggy code.
Oh, and speaking of generics and type erasure, the #2 exception on the
official 10 Most Annoying If They Became Checked Exceptions list
is ... you guessed it ... ClassCastException...
Twisted
> On Jul 2, 5:27 pm, Joshua Cranmer <Pidgeo...@verizon.net> wrote:
> > @ Language-level XML support
>
> Don't care. Sounds like an unholy mess.
Rather than "Against. Sounds like an unholy mess."? :)
I just looked at the proposal. An example given:
Example:
elt.appendChild(
<muppet>
<name>Kermit</name>
</muppet>);
Against, with "it's pointless" as my reason. We only need to maybe add
an appendChild(String) method that parses its argument, and:
elt.appendChild(
"<muppet>" +
" <name>Kermit</name>" +
"</muppet>");
is legal Java with the required semantics. All you lose is compile-
time linting of the XML literals and pre-construction of XML objects.
It sounds like that's basically what was proposed anyway -- just XML
literals. Nothing fancy like the language-extensibility as I suggested
earlier. All it would do is a) give compile-time checking of the XML
code for well-formedness and b) give you preconstructed objects at run-
time, saving a little time when an appendChild(String) method would
have to parse and construct elements instead of an
appendChild(XMLElement) method getting a ready-made one on a silver
platter. I think there are bigger bottlenecks out there.
> > @ Reified generics
>
> Also don't know what this is/Don't care. If my bugs are due to type
> casting of array elements then I have bigger problems than the version
> of my programming language.
Problems of the "Oops, I used an array instead of ArrayList again"
sort? ;)
> > @ Superpackages
>
> Don't know. Would have liked for the CLASSPATH problem to never have
> been created. It is the same as the lib/DLL hell and include path
> problems of yesteryear. If Superpackages fixes that then yes. I
> haven't studied but guess it is like Maven with net-based JAR linking.
I looked at this too now and it looks ... complicated. I thought JAR
files had largely superseded CLASSPATH problems, and JWS had largely
superseded JAR problems?
There will always be problems with shared code. If I create a library
Foo 1.0 and later, with the same package names and class names, a non-
backward-compatible Foo 2.0, and Joe creates Bar which uses Foo 1.0
under the hood, and Fred creates Baz which uses Foo 2.0 under the
hood, and Joe won't update Bar to work with Foo 2.0, and someone
writes application Quux which uses Bar and Baz ...
Well, if Bar can come with a "private" copy of Foo 1.0 it uses
internally, and Baz with a "private" copy of Foo 2.0, the problem
looks solved.
Until the author of Quux gets to the bit where he needs to write
BarObject futzmeier = new BarObject(someArguments);
futzmeier.doSomethingWith(aFooObject)...
and Foo 1.0 isn't visible.
OK, so he can include another copy of Foo 1.0 for Quux to use, but now
aFooObject might not look right to doSomethingWith because its run-
time class is a copy of FooObject loaded with one classloader and
doSomethingWith is expecting one whose run-time class is a different
copy of FooObject, loaded with another classloader.
Confused yet? Now picture
someBazObject.doSomethingElseWith(anotherFooObject)...
which needs a Foo 2.0 object...
*bangs head against wall*
The solution is really very simple. Do not make backward-incompatible
changes to libraries without also changing the package name. Put the
major version number somewhere in the package name! If everyone did
this, either Quux shipped with Bar, Baz, and Foo 2.0 would work, with
Bar accepting Foo 2.0 as a substitute for Foo 1.0, or else Quux comes
with Bar, Baz, Foo1.0, and Foo2.0, with the latter two not clashing as
one is com.foo.version1 and the other is com.foo.version2 ...
Unfortunately (or maybe fortunately), enforcing this worldwide is
nontrivial. :)
Then there's no need for "modules" with "hidden" JARs and all that
cruft. Just JARs, and a central place people can put the highest
version of a JAR they have to get rid of disk space wastage from
duplication...
(Sun itself is guilty of breaking backward compatibility. How many
times have we had someone complain here when something with "enum" in
it futzes up? The final straw being that apparently there's a whole
damn package out there with "enum" in its name, which is now useless
with anything later than Java 4...)
> One thing I would like to see is very tight integration with Linux.
> With Linux being Open Source then Sun could feasibly write a kernel
> module and maybe speed up the JVM on Linux I would guess.
What, and have all Java applications run with root privileges? Are you
fucking nuts? No amount of speedup is worth that.
Tom Hawtin
>
> Secondly, operators are then just syntactic sugar as follows:
> x * y -> x.multiply(y)
I want to multiply my Matrix by five using: 5 * m
> It would be desirable to be able to set a thread-local MathContext for
> BigDecimal calculations and scope it somehow.
Ick. Best not call any other methods in that scope (for instance by
causing a class to load)...
> I'd suggest a more
> general "environment" or "context" mechanism built on a (hopefully
> speeded-up!) threadlocal mechanism, whereby you can use code like
ThreadLocal is already pretty fast. I believe it spends most of its time
in Thread.currentThread().
> do switch (threadlocal: expression) { ... stuff ... }
> It would be syntactic sugar for:
>
> Object t3dsfgr838 = someThreadLocal.get();
> someThreadLocal.set(expression);
> try {
> stuff
> } finally {
> someThreadLocal.set(t3dsfgr838);
> }
Why not just use a closure? In current syntax (with restricted closure):
someThreadLocal.with(expression, new Runnable() {
public void run() { ... stuff ... }
});
Or in my suggested syntax for anonymous inner classes, the same thing
only less restricted:
someThreadLocal.with(expression, ### { ... stuff ... });
In Gafter, et al, I believe (don't quote me) the equivalent is:
someThreadLocal.with(expression) { ... stuff ... }
> And of course ThreadLocal should be made a) faster to access (at least
> to just read) and b) generic (so with a ThreadLocal<String>, you would
> not have to cast theThreadLocal.get() to String, etc.; why was this
> done promptly for WeakReference et. al. but not ThreadLocal? Arrrgh!)
(a) It is quite fast in comparison to BigDecimal operations.
(b) ThreadLocal is generic. IIRC, the example wasn't generified in 1.5.
In 1.6 the example has a bug (not from the original author).
http://java.sun.com/javase/6/docs/api/java/lang/ThreadLocal.html
Tom Hawtin
Twisted
> 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.
Static analysis tools are no substitute for human judgment, however.
If it finds "catch (Exception e)" in the code, don't instantly jump to
the alarm switch and break the "in case of emergency, break" glass;
first look at the code in question. It may turn out to be a perfectly
harmless and legitimate
catch (Exception e) {
myLogger.log(e.toString());
throw e;
}
Twisted
> Would have been nice if you had numbered the items. =P
Yeah, it really was rather inconsiderate of the OP to assume that all
of the experienced IT professionals with years of experience and
schooling here would be able to count as high as seven. ;)
Twisted
>
> 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:
>
> @ Closures
> @ Reified generics
> @ Superpackages
And here are the good, bad, and ugly ones that weren't listed above
and for which I have particular comments:
> Short instance creation
> Description: Allow a more compact syntax for creation of local
> variables to avoid repeating the assignment type and the
> constructor.
This better just add the ability to write StringBuffer foo = new();
without making it impossible to do e.g. List structureList = new
ArrayList();
Sometimes you want the reference to be of interface or superclass
type. For example, you can change that to ...new LinkedList(); later
without breaking any other code in the method.
> Comparisons for Enums
> Description: Allow enum values to work with range operators
> (<, >, etc)
> Example:
> boolean isRoyalty(Rank r) {
> return rank >= Rank.JACK && rank != Rank.ACE;
> }
Now just add allowing "case foo-bar:" in switch statements and we're
golden. Someone elsewhere in this thread lamented the lack of this
facility in current Java.
Of course, this should be done by providing operator overloading in
the manner I suggested elsewhere in this thread, with <= and >= and
their ilk usable on anything where the LHS implements Comparable<RHS>
or vice versa. (Where this means it implements Comparable<Foo> for
some Foo assignable from the compile-time type of the RHS.) If both
implement Comparable, the LHS's comparison method gets used. And of
course if they aren't already enums get Comparable and "case foo-bar:"
boils down to "if (x >= foo && x <= bar) {" with further translation
for the >= and <= operators.
> invokedynamic
> JSR 292
> Description: Introduces a new bytecode invokedynamic
> for support of dynamic languages."
I don't see what this buys us. No current or proposed legal Java code
would compile to bytecodes that would use this instruction. If this
affects anything, it's only non-Java languages that target the JVM.
Which makes it not a change to Java at all and irrelevant here.
David Gourley
The tool we use would not report this as an error (because the exception
is re-thrown).
On the other hand code that catches Exception and does not rethrow it is
just plain evil.
Dave
Guillermo Schwarz
> Joshua Cranmer wrote:
>
> > @ Closures
>
> But we already have (minimal) closures. I think it would be much more
> sensible to improve what we already have, rather than to duplicate. It's
> probably unlikely to get in before Java 1.8 anyway.
We already have Runnable. Who needs something else? Although it would
be nice if it were a la Smalltalk:
new Thread( new Runnable() { public void run() { doSomething(); } } );
Would become:
new Thread( <quote> doSomething(); );
Where <quote> could be:
1. [] a la Smalltalk, ie: [ doSomething(); ] It would look ugly in
Java, though.
2. ' (quote) a la Lisp, ie: 'doSomething(); It looks horrible in Java,
so forget about it.
3. # a la Smalltalk, ie: #doSomething(); Not bad, eh?
>
> > @ Strings in switch statements
>
> Not too fussed. It'll make switches on strings clearer, but perhaps will
> encourage poor code.
Simply use hashCode(), ie:
switch( str.hashCode() )
{
case "hello".hashCode(): ...; break;
case "bye".hashCode(): ...; break;
}
>
> > @ Operator overloading for BigDecimal
>
> BigDecimal and BigInteger are hideous to use at the moment. The overflow
> semantics of primitive integers are not something that I think should be
> in a high level language. I'd prefer general operator overloading of
> sensible operators.
It would be nice if all numerical classes in Java were retrofitted to
descend from Number (or implement Number), so that you could declare a
number and it could contain any number: float, int, bigdecimal, etc.
>
> > @ Language-level XML support
>
> Evil and unnecessary. A lot like much of XML.
Use XStream instead.
>
> > @ Reified generics
>
> This could have made sense in 1.5. But I don't think this is really on
> given the situation we have got ourselves into.
What do you mean?
>
> > @ Superpackages
>
> Good. I guess packages provide what is necessary from superpackages, but
> we tend to write libraries and applications in more than one package.
What is a superpackage?
Is it this? http://blogs.sun.com/gbracha/entry/developing_modules_for_development
I hope not.
First, EJB already have modularization, you deliver 2 jars, one for
use on the client and another for the whole implementation. It is
trivial (some could argue), but it already works.
The same approach could be used for super packages, have some "client"
package and stuff subpackages inside, and another "implementation"
package and stuff everything else, so that all interfaces and Transfer
Objects go into the "client" packages, and the rest have all the
implementations of those interfaces, great!
EJB was a dead horse because the Enterprise Java Beans did not need to
implement the remote interfaces, and besides the home interfaces were
unnecessary. If they had only one interface and one class (it could
have many implementations, but follow the idea for a minute), it would
be nice.
>
> > @ Removing checked exceptions
>
> I like static type checking.
Sometimes it gets in the way, but you can always convert those to
RuntimeException, what is the big deal?
Why does people need to force other into their preferences?
>
> Tom Hawtin
Twisted
> Tom Hawtin <use...@tackline.plus.com> writes:
> >> x * y -> x.multiply(y)
> >I want to multiply my Matrix by five using: 5 * m
>
> I'd prefer:
>
> x * y -> new BigDecimalPair( x, y ).multiply()
[snip stuff with static methods, friends...]
Yuck. Complicated. Ugly.
x op y with only one reference type is handled by dispatching on the
reference-type argument, and looking for its compile-time type to have
a suitable valueOf() static method. E.g.:
5 * m -> m.multiply(Matrix.valueOf(5));
So a static, Matrix-returning valueOf method that accepts one integer
argument needs to be in the class Matrix in this case, and if
MatrixReloaded is the actual runtime type of m,
MatrixReloaded.multiply (but just Matrix.valueOf) actually gets
called.
And of course 5 - m would be m.subtract(Matrix.valueOf(5)).negate(),
versus m - 5 being m.subtract(Matrix.valueOf(5)) -- this means we need
a reciprocal() method in Matrix for 5/m to be legal of course. It
should be allowed to throw anything, to accomodate your
MatrixNotInvertibleException, which if a checked exception needs to be
handled or declared by the method with the "5/m" expression in it.
(To get the expected behavior from e.g. 5*m requires Matrix.valueOf(5)
return a matrix with fives on the diagonal entries and zeros
everywhere else. This doesn't seem especially efficient, but
Matrix.valueOf(5) could return a ScaleMatrix subclass that has the
same overhead for creation and use as an Integer.valueOf(5). Matrix
can double-dispatch multiply(), resulting in
scaleMatrixFive.multiply2(m) basically occurring. And that, in turn,
could just boil down to "return m.scalarMultiply(5)". Or Matrix can
specifically check its parameter for being a ScaleMatrix with
instanceof or an isScaleMatrix() method call or whatever. And if
Matrix doesn't do some of these efficient things, someone can write a
subclass MatrixRevolutions that does!)
Guillermo Schwarz
use HashMaps instead of switch statements.
On Jul 3, 7:40 am, julien.robins...@gmail.com wrote:
Guillermo Schwarz
wrote:
> On Mon, 02 Jul 2007 21:27:16 GMT, Joshua Cranmer
> said :
>
> >@ Closures
>
> Not keen. I think this will needlessly make code hard to understand by
> the general programmer.
Not really if they are implemented a la Smalltalk.
For example:
if ( x > 0 ) { doSomething( x + 1 ); }
else { doOther( x - 1 ); }
could be written:
cond1 = #[ x > 0 ]; // #[] means delayed evaluation. cond1.eval() will
execute
cond2 = #[ fun( fun a, fun b ) { if ( cond1.eval() ) a.eval(); else
b.eval(); } ];
// since cond1 is delayed, cons1.eval() will execute.
// fun means function, fun a means a is a function.
// A function without a name is written simply fun(...parameters...)
cond2.eval( #doSomething( x + 1 ), #doOther( x - 1 ) );
// cond2 also was delayed, in order to execute,
// 2 functions need to be passed as parameters
// please note that any 2 functions could be passed
// #doSomething( x + 1 ) means pass the function instead of the
result.
>
> >@ Strings in switch statements
>
> Not as big as deal as it once was now there are enums. The feature
> will encourage inefficient code. I would like instead RANGES of ints
> and enums that generate better code and code easier to maintain than
> you would do manually. This is a relatively trivial extension,
> requiring no JVM change. Seehttp://mindprod.com/projects/caserange.htmlfor what I a would like.
Wouldn't it be better to use RangeHashMap and closures?
>
> >@ Operator overloading for BigDecimal
>
> fine. This can probably be done without a JVM change.
>
Actually the source for:
a + b
shoudl be replaced with:
a.operator_plus( b );
So it can be done trivially by the compiler.
>
> >@ Reified generics
>
> I don't know what that means. Reify means to regard or treat (an
> abstraction) as if it had concrete or material existence. Does this
> mean tossing out type erasure? Generics are an embarrassment to the
> language. I personally would like to start from scratch and see if
> they can be made 10 time times simpler and wart-free.
>
What are the problems you are seeing in Generics?
It was supposed that generics fixed what C++ templates screwed, but
since I worked in C++, I felt templates were a good idea at the
beginning and then they were totally messy. It simply doesn't scale.
Roedy Green
<guillerm...@gmail.com> wrote, quoted or indirectly quoted
someone who said :
> case "hello".hashCode(): ...; break;
> case "bye".hashCode(): ...; break;
That won't always work. Hashcodes are not completely unique.
Guillermo Schwarz
Map map = new HashMap();
map.put( y, #doThis() );
map.put( z, #doThat() );
map.put( null, #doSomethingElse() );
map.put( Default, #giveUp() );
map.switchOn( x );
On Jul 3, 11:10 am, "Oliver Wong" <o...@castortech.com> wrote:
> <julien.robins...@gmail.com> wrote in message
Twisted
wrote:
> We already have Runnable. Who needs something else? Although it would
> be nice if it were a la Smalltalk:
>
> new Thread( new Runnable() { public void run() { doSomething(); } } );
>
> Would become:
>
> new Thread( <quote> doSomething(); );
>
> Where <quote> could be:
> 1. [] a la Smalltalk, ie: [ doSomething(); ] It would look ugly in
> Java, though.
> 2. ' (quote) a la Lisp, ie: 'doSomething(); It looks horrible in Java,
> so forget about it.
> 3. # a la Smalltalk, ie: #doSomething(); Not bad, eh?
Nope, but we still don't have ones with generic argument and return
types ... of course, for use with threads, you want some sort of
ResultHolder and in the Runnable:
synchronized (resultHolder) {
resultHolder.set(someObject);
resultHolder.notify();
}
instead.
For this, I suppose a Foo[1] is usable for a result of type Foo.
> > Not too fussed. It'll make switches on strings clearer, but perhaps will
> > encourage poor code.
>
> Simply use hashCode(), ie:
>
> switch( str.hashCode() )
> {
> case "hello".hashCode(): ...; break;
> case "bye".hashCode(): ...; break;
>
> }
Hashcodes aren't guaranteed to be unique. They could be used under the
hood to speed up switches on reference types, whose cases are
constants; a premade HashMap can be used at runtime to lookup a
closure that was built by the compiler to actually contain the case
body bytecode, and the found closure invoked or else a default closure
is invoked. Cases with fallthrough produce closures that chain to
other closures under the hood.
> It would be nice if all numerical classes in Java were retrofitted to
> descend from Number (or implement Number), so that you could declare a
> number and it could contain any number: float, int, bigdecimal, etc.
Ultimately, to do any serious math nicely means you need either double
dispatch to be easy to do nicely, or a "ladder" or directed acyclic
graph of potentially implicit type promotions, based on the providing
of Foo.valueOf(bar) static methods in more advanced types to upconvert
lowlier ones, including primitives. So we'd end up with
short
| \
int float
| \ |
long double
| \ |
BigI-BigD
And of course there's third party types. What about vectors, tensors,
matrices, and suchlike? What about custom bignum types, which may have
different requirements and characteristics? (JScience has a
LargeInteger with faster multiplies at large sizes, a Real
representing an error-bounded quantity, and suchlike; it unfortunately
does not provide a LargeDecimal with the LargeInteger multiply...)
> > > @ Removing checked exceptions
>
> > I like static type checking.
>
> Sometimes it gets in the way, but you can always convert those to
> RuntimeException, what is the big deal?
>
> Why does people need to force other into their preferences?
Because unemployment of professional soldiers would skyrocket if there
were no fascist pigs in the world for them to either a) fight against
or b) work for. :P
Guillermo Schwarz
> >
> > @ Closures
>
> I'm sort of dreading this change, because it means once Java 7's out,
> I will no longer consider myself a competent Java programmer. On the other
> hand, might be a good opportunity to finally learn what closures are all
> about.
They are not a big deal, just reduce the clutter of Runnables and
write the code directly as a parameter, assign the code to a variable
(and tell it precisely when to execute). Purists will say that I'm
describing anonymous functions, well maybe. Java now has anonymous
classes and Java purists said anonymous functions and anonymous
classes were equivalent. Probably they were computationally
equivalent, but I certainly don't want to program in Turing. ;-)
>
> > @ Operator overloading for BigDecimal
>
> I thought "No Operator Overloading" was an argument for favoring Java
> over C++. The purist in me is already annoyed with the + operator being
> overloaded for Strings. This seems like a step in the wrong direction.
Generics were IMHO a big step in the wrong direction.
Operator overloading is complex in C++ becasue you can overload =, +=,
-=, etc. and not make them equivalent.
In Java, operator overloading should only be used for: +, -, * and /,
and their meaning should therefore let programmers write a += b and
automatically replace that by a = a + b (which would get then
translated to a = a.operator_plus( b );) No harm done.
>
> > @ Removing checked exceptions
>
> I like checked exceptions. I'm part of the crowd that is willing to do
> more typing in exchanged for less buggy programs.
If you don't want to use checked exceptions you could always use
RuntimeException. One size does not fit all.
Roedy Green
quoted or indirectly quoted someone who said :
>
>Benchmark running - Please minimize activity of other processes.
>The columns
> Identification number of the outermost iteration
> Runtime of "if" divided by runtime of "switch"
> Average of the preceding column
>
> 0; 0,73; 0,73
> 1; 0,93; 0,83
> 2; 0,93; 0,87
> 3; 0,93; 0,88
> 4; 0,93; 0,89
> 5; 0,93; 0,90
> 6; 0,93; 0,90
It depends on whether you use -client or -server
Here is Java 1.6 on my AMD 64 DUAL core 2.047 Mhz
java -client SwitchTester
Benchmark running - Please minimize activity of other processes.
The columns
Identification number of the outermost iteration
Runtime of "if" divided by runtime of "switch"
Average of the preceding column
0; 1.18; 1.18
1; 1.19; 1.19
2; 1.14; 1.17
3; 1.09; 1.15
4; 1.27; 1.17
5; 1.18; 1.18
6; 1.18; 1.18
java -server SwitchTester
enchmark running - Please minimize activity of other processes.
he columns
Identification number of the outermost iteration
Runtime of "if" divided by runtime of "switch"
Average of the preceding column
0; 0.75; 0.75
1; 0.94; 0.85
2; 0.82; 0.84
3; 1.11; 0.91
4; 0.86; 0.90
5; 0.84; 0.89
6; 0.91; 0.89
7; 0.85; 0.89
8; 0.91; 0.89
9; 0.86; 0.89
10; 0.78; 0.88
11; 0.92; 0.88
12; 0.83; 0.88
With Jet 5.0
Benchmark running - Please minimize activity of other processes.
The columns
Identification number of the outermost iteration
Runtime of "if" divided by runtime of "switch"
Average of the preceding column
0; 0.57; 0.57
1; 0.87; 0.72
2; 0.93; 0.79
3; 0.92; 0.83
4; 1.03; 0.87
5; 0.65; 0.83
6; 0.96; 0.85
7; 0.97; 0.86
So it looks like optimisers spend more time on IFs than SWITCH.
This is puzzling. Iin Assembler a jump table should be much faster
than any nested set of switches, even if organised in a binary search.
The -genasm+ switch in Jet seems to be discontinued so I can't easily
figure out what sort of code it is generating for both.
Roedy Green
<guillerm...@gmail.com> wrote, quoted or indirectly quoted
someone who said :
>> Not keen. I think this will needlessly make code hard to understand by
>> the general programmer.
>
>Not really if they are implemented a la Smalltalk.
I think you made my point.
Roedy Green
<see_w...@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :
>So it looks like optimisers spend more time on IFs than SWITCH.
>This is puzzling. Iin Assembler a jump table should be much faster
>than any nested set of switches, even if organised in a binary search.
I am wondering if parallel logic in the chip is the secret of the
speed of the nested if. Perhaps it can do several lookaheads.
Roedy Green
<ow...@castortech.com> wrote, quoted or indirectly quoted someone who
said :
> I thought "No Operator Overloading" was an argument for favoring Java
>over C++.
the problem is not operator overloading, when the overloaded operators
follow the usual rules of math. The problem comes with totally
unrelated functions are assigned operators, e.g. C++ reusing the shift
operators for i/o, or Java reusing + for contatenation.
Twisted
wrote:
> On Wed, 04 Jul 2007 00:38:06 GMT, Roedy Green
> someone who said :
>
> >So it looks like optimisers spend more time on IFs than SWITCH.
> >This is puzzling. Iin Assembler a jump table should be much faster
> >than any nested set of switches, even if organised in a binary search.
>
> I am wondering if parallel logic in the chip is the secret of the
> speed of the nested if. Perhaps it can do several lookaheads.
Could be. Branch prediction is clobbered by jump tables. I wonder if
dynamic method dispatch uses a binary tree approach instead of vtable
approach to take advantage of branch prediction in any of these VMs or
in Jet?
As for examining the assembly produced by Jet, why not simply
disassemble the object code it outputs?
Jacques-Olivier Haenni
Guillermo Schwarz wrote:
> If we had closures (and unnamed functions a la Smalltalk), we could
> use HashMaps instead of switch statements.
>
At my opinion, that's the very interesting thing in closures. You can
then add new functionalities such as the 'switch-on-map' mentionned in
some previous post, or an (enhanced) 'for each' loop, or some thread
management functionalities only by modifying the API, without any other
change to the JVM ! (The API is easier to modify than the JVM, whether
it be by one of us or even by Sun.)
Ok, this could be done already now in a large extent with anonymous
classes, but the amount of boilerplate code to write make such solutions
quite heavy to use.
JO.
Twisted
wrote:
> Ok, this could be done already now in a large extent with anonymous
> classes, but the amount of boilerplate code to write make such solutions
> quite heavy to use.
In a way, heavy use of closures for basic flow control and such is
"quite heavy to use" anyway, in terms of CPU and memory use. Have you
ever noticed that Smalltalk is v...e...e...e...e...r...r...r...y
s...l...o...o...o...w...w ?
CPUs themselves probably need a redesign to cope with the sort of code
in question. Procedural code with branching conditionals is what they
natively execute. In cases where closure-based constructs can be
compiled down to such a thing on a JIT basis you're golden, but
otherwise...
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>
>As for examining the assembly produced by Jet, why not simply
>disassemble the object code it outputs?
"simply"? Without symbol tables it is quite a bit of work to find the
code of interest, especially when it looks nothing like what you would
have written yourself.
I have a query into Jet about how to get the undocumented assembler
listing working again.
If that fails, my curiosity may press hard enough to solve this
mystery the hard way.
Hendrik Maryns
Hash: SHA1
Twisted schreef:
> On Jul 3, 5:31 am, Hendrik Maryns <hendrik_mar...@despammed.com>
> wrote:
>>> @ Removing checked exceptions
>> The only thing that I definitely support is the last one, but probably
>> in the unusual way: indeed, get rid of checked exceptions, by making
>> *all* exceptions checked.
>> For the skeptic: it can be done, see how Eiffel handles it.
>
> Are you out of your cotton-picking MIND?!
No.
> I don't want to have to
> declare every method as "throws RuntimeException" just because just
> about everything might throw NPE and any of several other assorted
> bounds, arithmetic, etc. exceptions. And if you want Error declared
> too, just forgeddaboudit.
Well, once all exceptions are checked, the throws X statement would be
superfluous anyway, so no argument.
> You'd have to massively redesign the language to make this have any
> beneficial effect,
Indeed, that’s why it is never going to happen. But I cannot follow
your argument which I snipped away, to be honest. I do not think it is
valid.
Once again: if you want to see how it can be done, have a look at Eiffel
error handling. It looks a bit minimalistic at first, but it is as
simple as it can get.
(http://docs.eiffel.com/eiffelstudio/general/guided_tour/language/tutorial-09.html)
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
iD8DBQFGi6Rme+7xMGD3itQRAqJuAJ9ffoUtfOx+FWHPju0OJTdzHcwLFACfXVRB
N3OSMFTpw2xLKeZ+e1gMnf4=
=TjT1
-----END PGP SIGNATURE-----
Roedy Green
someone who said :
>The -genasm+ switch in Jet seems to be discontinued so I can't easily
>figure out what sort of code it is generating for both.
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. However, that does not explain why AMD was slow too.
Unfortunately GenAsm in Jet, an undocumented feature to view generated
asm code, has been discontinued. To solve this I will have to find a
cheap decent disassembler. In the old 16-bit days I used one I liked
a lot called Sourcer, but his is no longer. I have compiled a list of
candidates at
http://mindprod.com/jgloss/disassembler.html
Joshua Cranmer
> Operator overloading is complex in C++ becasue you can overload =, +=,
> -=, etc. and not make them equivalent.
You can also overload the ',' operator, as well as the '||' operator,
etc. (every operator, in fact, except the '.','::', and the '?:'
operators).
> In Java, operator overloading should only be used for: +, -, * and /,
> and their meaning should therefore let programmers write a += b and
> automatically replace that by a = a + b (which would get then translated
> to a = a.operator_plus( b );) No harm done.
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.)
Bjorn Borud
|
| 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.)
indeed, which is why "don't do that then" is the right answer :-).
-Bjørn
Roedy Green
quoted or indirectly quoted someone who said :
>final int random =(( randomizer / 65536 )& 0x7fffffff )% 10;
I look more carefully at the code, I see another problem.
Your code to calculate randoms overwhelms the cost of the code to do
the swtich.
I rewrote the code. Here is my new result with Jet.
[E:\com\mindprod\example]TestSwitch
Calculate time for IF/time for SWITCH. >1 means IF is slower
Trial | ratio | average
0 1.00 1.00
1 1.01 1.00
2 0.97 0.99
3 0.99 0.99
4 1.01 1.00
5 1.00 1.00
6 1.04 1.00
7 1.01 1.00
8 1.00 1.00
9 0.99 1.00
10 0.99 1.00
In other words IF is just as fast as switch WHY??
package com.mindprod.example;
import static java.lang.System.nanoTime;
import static java.lang.System.out;
import java.util.Random;
/**
* Compares relative speed of nested if vs switch
*
* @author Roedy Green, Canadian Mind Products, based on a program by
Stefan
* Ram.
* @version 1.0, 2007-07-04 Created with IntelliJ IDEA.
*/
public class TestSwitch {
// ------------------------------ FIELDS
------------------------------
// one million iterations per trial
final static long ITERATIONS_PER_TRIAL = 1000000L;
// --------------------------- main() method
---------------------------
public static void main( final java.lang.String[] args ) throws
java.lang.Throwable
{
out.println(
"Calculate time for IF/time for SWITCH. >1 means IF
is slower" );
out.println( " Trial | ratio | average" );
final Random wheel = new Random();
// accumulate total machine cycles for switch
long accumSwitchTotal = 0;
// accumulate total machine cycles for if
long accumIfTotal = 0;
// force code to do something rather than be optimised out of
existence
long forcer = 0;
// do forever
for ( long trial = 0; ; trial++ )
{
// accumulate machine cycles for switch for this trial
long accumSwitchTrial = 0;
// accumulate machine cycles for if for this trial
long accumIfTrial = 0;
for ( long i = 0; i < ITERATIONS_PER_TRIAL; ++i )
{
final int random = wheel.nextInt( 10 );
long start = nanoTime();
final int rif;
{
if ( random == 0 )
{
rif = 20418437;
}
else if ( random == 1 )
{
rif = 94704581;
}
else if ( random == 2 )
{
rif = 45898144;
}
else if ( random == 3 )
{
rif = 49094059;
}
else if ( random == 4 )
{
rif = 77416885;
}
else if ( random == 5 )
{
rif = 91322469;
}
else if ( random == 6 )
{
rif = 40218964;
}
else if ( random == 7 )
{
rif = 93641667;
}
else if ( random == 8 )
{
rif = 29822916;
}
else
{
rif = 625909;
}
}
accumSwitchTrial += nanoTime() - start;
forcer += rif;
start = nanoTime();
final int rswitch;
switch ( random )
{
case 0:
rswitch = 16336774;
break;
case 1:
rswitch = 62881795;
break;
case 2:
rswitch = 27998504;
break;
case 3:
rswitch = 9612956;
break;
case 4:
rswitch = 25592297;
break;
case 5:
rswitch = 77114095;
break;
case 6:
rswitch = 23554325;
break;
case 7:
rswitch = 55380051;
break;
case 8:
rswitch = 47971513;
break;
default:
rswitch = 41100793;
}
accumIfTrial += nanoTime() - start;
forcer += rswitch;
}// end for iterations
double ratio = (double) accumIfTrial / (double)
accumSwitchTrial;
accumIfTotal += accumIfTrial;
accumSwitchTotal += accumSwitchTrial;
double averageRatio =
(double) accumIfTotal / (double) accumSwitchTotal;
out.printf( "%6d %6.02f %6.02f\n", trial, ratio,
averageRatio );
Oliver Wong
news:u4gn8312pnnvdpvjk...@4ax.com...
>
> [E:\com\mindprod\example]TestSwitch
> Calculate time for IF/time for SWITCH. >1 means IF is slower
> Trial | ratio | average
> 0 1.00 1.00
> 1 1.01 1.00
> 2 0.97 0.99
> 3 0.99 0.99
> 4 1.01 1.00
> 5 1.00 1.00
> 6 1.04 1.00
> 7 1.01 1.00
> 8 1.00 1.00
> 9 0.99 1.00
> 10 0.99 1.00
>
> In other words IF is just as fast as switch WHY??
To clarify, when I said that switch-statements behave like a bunch of
if-statements, I meant at the semantic/behaviour level, not at the
performance level.
However, these experiments just seem to reinforce the dogma: "Don't
optimize without profiling; your intuitions about performance are probably
wrong."
- Oliver
Oliver Wong
"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
news:classes-200...@ram.dialup.fu-berlin.de...
> Bjorn Borud <borud...@borud.no> writes:
>>| 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.)
>
> That is one advantage of associating operators with pairs and
> not single operands.
>
> If "*" is associated with the left operand of type »int«,
> you can not overload it in C++ IIRC.
>
> In a fictional language, however, classes might also have pairs
> as their designation. In this language, the operator »*« would
> be associated with the class »( int, Matrix )«. This class is
> not inbuilt and, therefore, an overload is possible.
I definitely see the appeal of specifying the behaviour of binary
operators within class-pairs, rather than within a specific (but perhaps
arbitrary?) class. Maybe operators should not simply be thought of as
syntactic sugar for a method invocation on an object, but rather as first
class citizens of a language in their own right?
- Oliver
Roedy Green
<ow...@castortech.com> wrote, quoted or indirectly quoted someone who
said :
> To clarify, when I said that switch-statements behave like a bunch of
>if-statements, I meant at the semantic/behaviour level, not at the
>performance level.
You said " Yes, I think that's an accurate mental model of how the
switch statement works"
That sounded to me a description of how they behave under the hood. I
was puzzled when I read that which you meant.
We need a pair of adjectives:
1. one for a model describes the end result but is not necessarily
anything like how it is implemented.
2. one for a model that roughly describes what goes on at the machine
code level.
Chris Smith
Joshua Cranmer <Pidg...@verizon.net> wrote:
> 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:
>
> @ Closures
I have no opinion, because I haven't actually read through Neil's
proposal (I'm assuming Neil's proposal is what would happen here). I'm
skeptical, and there is a certain bar of "does it add anything?" that
would need to be cleared here.
> @ Strings in switch statements
> @ Operator overloading for BigDecimal
Of course, on both counts.
If operator overloading were being considered in a more general way,
there might be dispute between the two options. In the absence of
something more general, the only way to oppose it for BigDecimal is to
have never tried any non-trivial use of BigDecimal as it stands. This
is no different from operator overloading for String.
> @ Language-level XML support
Bleh. I'd like to see this idea hidden under mounds and mounds of dirt,
and the ground poisoned so that no one will go near it again. I'm
wondering when the proposal will come to add JSON syntax to the
language, and then YML, and then INI file format, and then...
Addiction to XML signifies the worst possible side of Java, and brings
out the ugliest in its developers. It's quite the tricky little devil,
too, as it has ensnared any number of people who otherwise think clearer
than that.
> @ Reified generics
YES!!!!!!!
YES!!!!
Oh, and YES!!!!!
(In other words, this feature means "fix the broken generics we wrote
the first time around.")
> @ Superpackages
Not sure what they are.
> @ Removing checked exceptions
This would be a serious, serious mistake. Improving checked exceptions
to fix their limitations is one thing. Removing them is the wrong
direction.
--
Chris Smith
Twisted
wrote:
> Indeed, that's why it is never going to happen. But I cannot follow
> your argument which I snipped away, to be honest. I do not think it is
> valid.
You can't snip the whole argument and handwave "I do not think it is
valid" and expect to be believed. Either respond in detail and marshal
some evidence to support your POV, or forget about it. 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. 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.
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...
Oliver Wong
news:f6g82v$ngi$1...@newsserv.zdv.uni-tuebingen.de...
>> On Jul 3, 5:31 am, Hendrik Maryns <hendrik_mar...@despammed.com>
>> wrote:
>>> get rid of checked exceptions, by making
>>> *all* exceptions checked.
>>> For the skeptic: it can be done, see how Eiffel handles it.
>
> Well, once all exceptions are checked, the throws X statement would be
> superfluous anyway, so no argument.
To me, a checked exception is one you have to either handle or
explicitly throw, and an unchecked exception is one which you do not need
to handle nor explicitly throw. The terms are only meaningful in contrast
to each other. I can't see a difference between a language which has only
"unchecked exceptions" (and thus you never need to declare a throw), and a
language which has only "checked exceptions" (and thus you never need to
declare a throw).
It may be more productive to focus the debate on:
1) Should there be a duality of checked vs unchecked exceptions, or
should there only be one type of exception?
and 2) If the latter, should this "only one type" of exception have
enforced throw declaration, or forbid any type of throw declaration
whatsoever, (or perhaps allow the throw declarations, but make them
optional, as a form of documentation, and have no effect on behaviour of
the program)?
FWIW, I think Sun got this part of the language design right and that
there is value in having two different types of exceptions.
- Oliver
Wojtek
> FWIW, I think Sun got this part of the language design right and that
> there is value in having two different types of exceptions.
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?
OTOH, if it throws an unchecked exception, then this is valid code, and
some other part of the JVM will catch it.
Note: This type of construct should ONLY ever fail during the coding
process, where the developer can fix it. I use it to to make sure that
the passed parameter is uniquely named.
Note2: There are other constructs to attach the new FooBar to the class
Foo, but they are not relevant to this discussion...
--
Wojtek :-)
Piotr Kobzda
> Oliver Wong wrote :
>> FWIW, I think Sun got this part of the language design right and
>> that there is value in having two different types of exceptions.
>
> 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
l...@mail.com
wrote:
> On Wed, 04 Jul 2007 00:38:06 GMT, Roedy Green
> someone who said :
>
> >The -genasm+ switch in Jet seems to be discontinued so I can't easily
> >figure out what sort of code it is generating for both.
>
> 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
> Roedy Green <see_w...@mindprod.com.invalid> writes:
>>> So it looks like optimisers spend more time on IFs than SWITCH.
>>> This is puzzling. Iin Assembler a jump table should be much faster
>>> than any nested set of switches, even if organised in a binary search.
>> I am wondering if parallel logic in the chip is the secret of the
>> speed of the nested if. Perhaps it can do several lookaheads.
>
> 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;
>
>
> 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
Hash: SHA1
Twisted schreef:
> On Jul 4, 9:45 am, Hendrik Maryns <hendrik_mar...@despammed.com>
> wrote:
>> Indeed, that's why it is never going to happen. But I cannot follow
>> your argument which I snipped away, to be honest. I do not think it is
>> valid.
>
> 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
> Wojtek wrote:
>> Oliver Wong wrote :
>>> FWIW, I think Sun got this part of the language design right and that
>>> there is value in having two different types of exceptions.
>>
>> 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);
> }
> }
> }
But does not the final keyword preclude this?
And I also get an error that BAR has not been initialized.
--
Wojtek :-)
Tom Hawtin
> 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?
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
> Wojtek wrote:
>
>> 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.
Eclipse gives the error.
--
Wojtek :-)
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>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?
Tom Hawtin
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> Tom Hawtin <use...@tackline.plus.com> writes:
>>>> x * y -> x.multiply(y)
>>> I want to multiply my Matrix by five using: 5 * m
>> 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#
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
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
> On Tue, 03 Jul 2007 23:28:03 +0000, Guillermo Schwarz wrote:
>> Operator overloading is complex in C++ becasue you can overload =, +=,
>> -=, etc. and not make them equivalent.
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
wrote:
> 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
wrote:
> 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
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
wrote, quoted or indirectly quoted someone who said :
>
>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.
~kurt
>
> 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.
Interesting.
Well, even something no so efficient would probably be better than
having to create objects and not be able to use standard operators
on them.
- Kurt
Twisted
Hendrik Maryns
Hash: SHA1
Twisted schreef:
Uh, no?
Not that I’d need complex numbers. Lisp has them, if you want.
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
iD8DBQFGnM6Ge+7xMGD3itQRAvMhAJoCQ5EDrMWIun6816X2S6mxu3JmFACdH95s
u10R0VjojcIQKj6lwVSpKdg=
=DUVs
-----END PGP SIGNATURE-----
~kurt
You would call complex numbers an unnecessary feature considering all the
other BS that Java has built into it? Unnecessary would probably be
along the lines of making it too general supporting hypercomplex numbers
(like quaternions). Really, it would be nice to be able to '+', '-', etc...,
complex primitives just like other numbers.
You computer scientists - don't seem to remember what computers were really
made for....
- Kurt
Lew
> You computer scientists - don't seem to remember what computers were really
> made for....
Accessing porn sites?
--
Lew
Joshua Cranmer
> You computer scientists - don't seem to remember what computers were
> really made for....
>
> - Kurt
Let's see, the first use I can think of would be to tabulate the 1890
census, so for basic statistics?
Or maybe you're referring to ENIAC, which would be calculating firing
tables for ammunition, so basic classical mechanics?
Calculating tedious logarithms?
Adding/subtracting/multiplying/dividing/exponentiating floating point
numbers?
How about the personal computer -> i.e., basic word processing?
How much of those require computing complex numbers?
~kurt
>
> Let's see, the first use I can think of would be to tabulate the 1890
> census, so for basic statistics?
Didn't know about that one (or didn't remember).
>
> Or maybe you're referring to ENIAC, which would be calculating firing
> tables for ammunition, so basic classical mechanics?
That is what I was thinking of.
>
> Calculating tedious logarithms?
>
> Adding/subtracting/multiplying/dividing/exponentiating floating point
> numbers?
>
> How about the personal computer -> i.e., basic word processing?
>
> How much of those require computing complex numbers?
Scientific/mathematical work benefits from having complex numbers. Modeling
and simulation, control theory, etc, come to mind immediately. As you have
pretty much pointed out, science and math are what computers were created for.
Everything else is just useless fluff that has not done much more for us
as a whole than find additional ways to become less productive and waste
more time (granted, the easy access to porn is not a waste of time). OK,
word processors are a lot nicer and more useful than the typewriter - I can
admit that.
I know, once C# adds complex numbers, we will finally see it in Java.
I'll have to start pestering Microsoft....
- Kurt
Patricia Shanahan
...
> I know, once C# adds complex numbers, we will finally see it in Java.
> I'll have to start pestering Microsoft....
I think pestering for complex numbers is a bit misdirected. The more
general problem is all the numeric types other than those that Java
implements as primitives. Here are a few that I can remember:
BigInteger
BigDecimal
general rational numbers
extended precision IEEE 754 (useful e.g. for calculating constants for
64 bit precision functions).
interval arithmetic
Any of these would be more usable with infix notation instead of writing
unreadable stacks of method calls.
There used to be optimization reasons for preferring a built-in type to
a class with infix notation, but with method in-lining I'm not sure they
are still valid.
Patricia
Roedy Green
quoted or indirectly quoted someone who said :
>Accessing porn sites?
see http://mindprod.com/project/pornviewer.html
Tim Slattery
>Joshua Cranmer <Pidg...@verizon.net> wrote:
>>
>> Let's see, the first use I can think of would be to tabulate the 1890
>> census, so for basic statistics?
>
>Didn't know about that one (or didn't remember).
That's what Herman Hollerith's punched cards were first used for.
Hollerith's company became IBM.
--
Tim Slattery
Slatt...@bls.gov
http://members.cox.net/slatteryt
Martin Gregorie
general mechanism. IMO allowing user-defined operator overloading would
fit the bill provided only that it was implemented similarly to to the
way Algol 68 did it.
In Java terms that would require something like a modified class
declaration. Something like:
public operator +
{
public Complex op (Complex a, Complex b)
{
.....
}
...ETC...
}
Usage:
Complex a,b,c;
real x,y,z;
a = b + c;
x = y + z;
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Martin Gregorie
> Martin Gregorie <mar...@see.sig.for.address> writes:
>> public operator +
>> {
>> public Complex op (Complex a, Complex b)
>
> is the name of a method. We do not define that method as:
>
> public method println
> { public void method( final java.lang.String string ) ... }
>
> So this would deviate from the hitherto Java design.
>
> My own preference would be the introduction of pair
> classes, like:
>
> public class( java.math.Complex, java.math.Complex )
> { public java.math.Complex +()
> { return new java.math.Complex
> ( this.0.real + this.1.real,
> this.0.imah + this.1.imag ); } ... }
>
> The name of this class would be:
>
> »( java.math.Complex, java.math.Complex )«
>
> Such an product class would be allowed, whenever an extension
> of each of the factor classes is allowed.
>
> The product class has access to all fields of each factor
> class (i.e., java.math.Complex) that an extension would be
> allowed to access.
>
> The product class is responsible for all operations on a pair
> of complex numbers.
>
> The expression
>
> »a + b«
>
> would behave as if a pair (a, b) of this class would be
> constructed and then has »+« invoked on the pair, even though
> the implementation is free not to really create such a pair
> object on the heap for efficiency.
>
> See also
>
> http://blogs.sun.com/jrose/entry/tuples_in_the_vm
>
I have no real argument with this approach.
I was thinking that if the operator was defined as a class equivalent
then the base operator 'methods' would define the base use of the
operator (and would be added to the java.lang package) and the 'extends'
keyword could be used to add arbitrary overloading to it by defining
additional methods.
Christian
> ~kurt wrote:
> In Java terms that would require something like a modified class
> declaration. Something like:
>
> public operator +
> {
> public Complex op (Complex a, Complex b)
> {
> .....
> }
>
> ...ETC...
> }
>
>
> Usage:
>
> Complex a,b,c;
> real x,y,z;
>
> a = b + c;
> x = y + z;
>
>
uuuh why so ugly ?
why not just add an interface to the api
public interface Addable<T> {
T add(T t1 , T t2);
}
and allow any implementing class to be used with + operator..
I think we don't really need some more syntax for the bits of operator
overloading that is acceptable and sometimes useful..
Christian
Twisted
> The expression
>
> »a + b«
>
> would behave as if a pair (a, b) of this class would be
> constructed and then has »+« invoked on the pair, even though
> the implementation is free not to really create such a pair
> object on the heap for efficiency.
And as a result, the method better not modify either argument. So your
suggestion effectively implies sneaking in "const" through the back
door. (But what about "notnull"?)
pkriens
> @ Closures
Only if done properly:
- correct return semantics (return from closure == return from
enclosing function)
- full access to local variables of the enclosing scopes
- efficient (i.e. not inner classes)
> @ Strings in switch statements
> @ Operator overloading for BigDecimal
Seems weird in Java to treat certain objects more equal than others?
Or make it a model where any object can be used or forget it. These
special cases are always error prone and hard to teach.
> @ Language-level XML support
And when we are at it, lets add embedded SQL! :-(
> @ Reified generics
Well, guess it makes sense if you like generics.
> @ Superpackages
The current way they intend to implement it sucks, you get the
information in 2 places (a central new type class file and in each
member class file). It is an interesting idea but the redundancy is
going to hurt. Not sure if it is worth it. Using runtime modules like
OSGi or maybe in the future JSR 277 work fine for me, they also allow
you to change membership in deployment which can be interesting if you
have to support different environments.
> @ Removing checked exceptions
Yes! Checked exceptions were the worst idea since stale bread.
Exceptions are perfect, but forcing a programmer to catch 15
exceptions only to wrap them in a 16th exception and throw it again is
dumb. There is a lot of bad API design out there because checked
exceptions.
Kind regards,
Peter Kriens
nebul...@gmail.com
No!
> Checked exceptions were the worst idea since stale bread.
Very original, and unfortunately very wrong.
> Exceptions are perfect, but forcing a programmer to catch 15
> exceptions only to wrap them in a 16th exception and throw it again is
> dumb. There is a lot of bad API design out there because checked
> exceptions.
Actually, there is a lot of catching and rethrowing out there because
of bad API design.
It's good and proper that the compiler tells you you should have a
strategy in place to handle I/O failure when you have finished writing
your I/O code, and things of that nature.
Having to catch and rethrow can be because of a bad API design where
an interface didn't specify likely exceptions.
Or it can actually mean nothing, in cases where a layer change means
the problem and solution language space changes and the exceptions
specific to the lower layer really should be transformed into
exceptions semantically meaningful in the context of the upper layer.
Unfortunately there seems to be no simple way to allow exception
throwing behavior to be parametrized in a generics-like fashion
without the result being a semantic and syntactic nightmare.
Lew
> On Jul 21, 6:16 am, pkriens <pkri...@gmail.com> wrote:
>>> @ Removing checked exceptions
>> Yes!
>
> No!
>
>> Checked exceptions were the worst idea since stale bread.
>
> Very original, and unfortunately very wrong.
>
>> Exceptions are perfect, but forcing a programmer to catch 15
>> exceptions only to wrap them in a 16th exception and throw it again is
>> dumb. There is a lot of bad API design out there because checked
>> exceptions.
>
> Actually, there is a lot of catching and rethrowing out there because
> of bad API design.
>
> It's good and proper that the compiler tells you you should have a
> strategy in place to handle I/O failure when you have finished writing
> your I/O code, and things of that nature.
Meaning that it is good and proper that the API designer contracted the client
to recognize those checked exceptions.
> Having to catch and rethrow can be because of a bad API design where
> an interface didn't specify likely exceptions.
Or specified too many, to address the OP's example. You are accurate to blame
the API design for this type of error; it's not Java's fault but the API author's.
> Or it can actually mean nothing, in cases where a layer change means
> the problem and solution language space changes and the exceptions
> specific to the lower layer really should be transformed into
> exceptions semantically meaningful in the context of the upper layer.
Excellent use case for exceptions.
> Unfortunately there seems to be no simple way to allow exception
> throwing behavior to be parametrized in a generics-like fashion
> without the result being a semantic and syntactic nightmare.
Twisted is absolutely correct down the line, except that I don't really mind
the way exceptions are generified currently. I also hope that the
implementation of closures (another bit of highly-demanded but questionably
practical fluff to add to Java) would address Exceptions in a fashion to avoid
that "nightmare".
Checked exceptions are an interface element put in place by the API designer.
If you don't like the "15 exceptions" that a method throws, blame the
programmer, not the language. It is useful to be able to declare checked
exceptions to force API clients to deal with them.
Every objection I've seen to checked exceptions has been rooted in laziness,
taken entirely from the API client's point of view. From the API author's
POV, checked exceptions are a way to prevent client-programmer laziness and
are invaluable. Let the lazy whine. Guess what? You have to check for
exceptions whether they're checked or not; checked means the compiler helps
you. Stop being lazy and use them properly.
--
Lew
nebul...@gmail.com
> If you don't like the "15 exceptions" that a method throws, blame the
> programmer, not the language. It is useful to be able to declare checked
> exceptions to force API clients to deal with them.
Or even blame yourself. If the API designer was at all intelligent
there be a single exception superclass of the 15 that doesn't catch
much else, e.g. it throws 15 varieties of IOException. You can just
catch IOException instead of all of the different subtypes in this
case. Of course if the API designer throws 15 various
TwiddleSticksFoobar related exception varieties and there's no common
TwiddleSticksFoobarException superclass then the API design is
boneheaded. If its client contract has nothing to do with parsing but
simply with accessing an abstract persistent store, a bunch of XML
exception throws clauses is a bad sign -- it should really translate
those into something like a FudgewobblyDataCorruptException clearly
related to its own purpose with the XML exceptions wrapped as "cause"
exceptions, and throw the same exception type if it hits something
that throws NumberFormatException, etc. while reading in the data. All
of these specific exceptions from the data-slurping layer mean "the
file is mangled and unreadable, no longer well-formed, kaputnik" after
all.
Joshua Cranmer
> uuuh why so ugly ?
>
> why not just add an interface to the api
>
> public interface Addable<T> {
> T add(T t1 , T t2);
> }
>
> and allow any implementing class to be used with + operator..
That means that you would be calling:
Addable<T> T1, T2, T3;
// initialize
T1.add(T2,T3);
For various reasons, operator overloading tends to work better as a
global method with the lhs and rhs as arguments. This is because M1 * 5
logically equals 5 * M1 but 5, being a primitive type, cannot have an
operator*(M) function. The hard part is trying to figure out where to put
this global method given Java's class model.