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.
