Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies:
23 -
Pages:
2
[
Previous |
1
2
]
Fresh Jobs for Developers Post a job opportunity
» Dieselpoint, Inc seeks a Senior Solution Engineer - Enterprise Search in Chicago, IL 60661 » DZone, Inc. seeks a DZone Developer Intern in Cary, NC
Re: Closures Consensus. FCM, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> I'm sorry, I just don't feel that the benefits of> closure are greater than the cost it brings (at least
> in its current form). I wish you could just access
> the non-final fields using the existing syntax. Just
> my 2 cents.
>
> Gili
there is no benefit. It's function pointers to "replace" (anonymous) inner classes, a more dangerous and errorprone alternative to something that works quite well, proposed for the sake of the proposal.
Change for the sake of change...
Switch on Strings
> > Plus, the compiler could> > probably generate code that's more efficient
> than a
> > naive 'if..else if..else if..' sequence.
>
> There's no information in a switch statement that the
> compiler could not glean from a nested if..else tree.
A switch on strings can be implemented using a bytecode-level switch statement on the hashcode of the string followed by an equals() check. This can be done so long as the strings are constants (as works because they are immutable)
A cautious welcome, but no consensus
I have blogged my response to the JSR announcement .In summary I'm giving the JSR a cautious welcome, but wish to emphasise that there is no new consensus beyond that there should be a JSR.
Re: Switch on Strings
> A switch on strings can be implemented using a> bytecode-level switch statement on the hashcode of
> the string followed by an equals() check. This can be
> done so long as the strings are constants (as works
> because they are immutable)
A compiler can generate the same code for an if/else if sequence that only tests a value against various strings. There is no reason low-level implementation detail has to be exposed to the programmer; the compiler can do as good or better a job of inferring these things. This is also why fixed-width integer types and primitives which don't obey object semantics are problematic.
Re: Switch on Strings
Stephen,I don't think String.hashCode() implementation
is a part of the spec.
I know that at least Harmony and SUNjdk doesn't have
the same implementation.
So your trick will not work.
Rémi
Re: Switch on Strings
> Stephen,> I don't think String.hashCode() implementation
> is a part of the spec.
> I know that at least Harmony and SUNjdk doesn't have
> the same implementation.
>
> So your trick will not work.
It will work fine, because of the equals check.
Re: Switch on Strings
> A compiler can generate the same code for an if/else> if sequence that only tests a value against various
> strings. There is no reason low-level implementation
> detail has to be exposed to the programmer; the
> compiler can do as good or better a job of inferring
> these things. This is also why fixed-width integer
> types and primitives which don't obey object
> semantics are problematic.
Indeed. The only reason to expose that is if you have a performance consideration that you don't expect your language to outlive.
Re: Switch on Strings
> I don't think String.hashCode() implementation> is a part of the spec.
It is part of the spec.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> Perhaps you know some use cases for switches on Strings that have eluded me.How about the point in time when you don't have objects (yet)?
I agree that code littered with decision constructs (chains of if-else if-else if... or switches) may very well betray that its author doesn't understand polymorphism. But processing command-line args, data from a file or database, etc. are places where Java code has to deal with the outside world of strings, integers, etc. Making decisions over string values more awkward than necessary, simply because that capability CAN be misused, seems a bit like nose amputation to me.