I think your view of history is tainted somewhat, for some reason. Why would this get you lynched, exactly? That delegate article is from the stone age and clearly no longer represents any relevant current opinions, given what Project Lambda is all about.
As to the OP's performance concern: Seeing is believing. Like any other small-fry performance issue, run a profiler, because the JVM optimizers far too much for you to be able to figure out what's going to happen, performance wise, given a piece of code (unless we're talking algorithmic complexity of course). I bet you'll never notice. Op vrijdag 29 april 2011 06:16:53 UTC+2 schreef Casper Bang het volgende: > > Hehe a few years ago, these comments would've gotten you guys lynched > on this forum. Times sure does change. ;) > I am surpriced the article is still up, given what's happening with > JDK7/8. > > /Casper > > On Apr 28, 9:55 pm, Ricky Clarkson <[email protected]> wrote: > > And here is the incredibly stupid article in which they did so: > http://java.sun.com/docs/white/delegates.html > > > > -- > > Skype: ricky_clarkson > > UK phone (forwards to Skype): 0161 408 5260 > > > > 2011/4/28 Cédric Beust ♔ <[email protected]>: > > > > > > > > > > > > > > > > > FYI, that's what Microsoft did with delegates, back in the J++ scandal > days. > > > I didn't agree with the political motivation but the idea has always > made > > > sense to me and I was sad to see it shoot down so stupidly by Sun. > > > -- > > > Cédric > > > > > On Thu, Apr 28, 2011 at 10:52 AM, Alexey Zinger <[email protected]> > > > wrote: > > > > >> As I was looking at some code today that used FP concepts with Guava > > >> (Google Collections), I saw the same pattern I see over and over in > such > > >> Java code that strives to be expressive in a functional manner: a > function > > >> is required as a parameter for some operation and it so happens that > the > > >> code that sends that function along instantiates the Guava Function > object > > >> (or something similar, like Comparator) there and then. The look of > the > > >> code is as close to what we can expect to see in a "true" functional > > >> language with current Java capabilities, but more often than not, the > > >> purpose of including the guts of the function right there is to bundle > the > > >> function definition with its logical context, not because we really > need to > > >> instantiate the object in that place. In fact, typically, the > anonymous > > >> inner class expressing said function always produces identical > instances. > > >> Here's a hypothetical example. Let's assume the following gets called > a lot > > >> throughout the uptime of the program: > > > > >> final List<String> lowerCaseList = ...; > > >> final List<String> upperCaseList = Lists.transform(lowerCaseList, new > > >> Function<String, String>() { > > >> public String apply(String s) { return s.toUpperCase(); } > > >> }); > > > > >> This is quite readable, but in theory, the following would be more > > >> efficient: > > > > >> final List<String> lowerCaseList = "..."; > > >> final List<String> upperCaseList = Lists.transform(lowerCaseList, > > >> toUpperFunction); > > > > >> where toUpperFunction is defined elsewhere, ensuring a more > appropriate > > >> lifespan to the instance. Is there a JVM optimization that developers > can > > >> reasonably rely on, that would effectively promote this particular > > >> apply(String) implementation to a "static" level, so that no instance > memory > > >> would need to be allocated and reclaimed, and no constructor would > need to > > >> be called? And if not, is this on the order of magnitude, where it's > > >> generally not a concern in performance-sensitive scenarios? > > > > >> Alexey > > >>http://azinger.blogspot.com > > >>http://bsheet.sourceforge.net > > >>http://wcollage.sourceforge.net > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "The Java Posse" group. > > >> To post to this group, send email to [email protected]. > > >> To unsubscribe from this group, send email to > > >> [email protected]. > > >> For more options, visit this group at > > >>http://groups.google.com/group/javaposse?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "The Java Posse" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
