I actually don't mind their stand on this, so long as the small inefficiencies can be JIT'ed away with a little bit of cleverness.
Alexey ________________________________ From: Ricky Clarkson <[email protected]> To: [email protected] Sent: Thu, April 28, 2011 3:55:05 PM Subject: Re: [The Java Posse] question about JVM optimizations and instantiating stateless "function" objects 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. -- 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.
