Generally, it's the readability that affects me more than the performance. -- Skype: ricky_clarkson UK phone (forwards to Skype): 0161 408 5260
On Thu, Apr 28, 2011 at 5:16 PM, Alexey Zinger <[email protected]> wrote: > 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. > -- 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.
