Well, what was described was part of the embrace and extend for the billionth time.
Kirk On Apr 30, 2011, at 9:11 AM, Reinier Zwitserloot wrote: > That's such a ridiculous twist on what actually happened that I'm half > convinced your Steve Ballmer's alter ego. > > It was microsoft playing the embrace and extend game for the billionth time.. > and clearly breaking the contract they signed with sun. > > Op vrijdag 29 april 2011 20:06:45 UTC+2 schreef Casper Bang het volgende: > Microsoft added stuff to their version of Java (delegates...), while > removing other things (JNI...), which Anders Hejlsberg thought were a > terrible mess. Microsoft was eventually forced to name it J++ and show > a disclaimer that this wasn't Java... essentially forcing Microsoft to > go back to the drawing board and come up with what would eventually > becomes C#. Since then, a lot of other stuff has shown up in > "Microsoft's version of Java" only to be added to the official Java > later (enum's, annotation etc.), lately it's dynamic language support, > automatic resource management, lambda expressions etc. > > On Apr 29, 5:38 pm, Kirk <[email protected]> wrote: > > Rewrite of history. MS wrote Windows specific extensions that would have > > bound Java to Windows. I don't see that happening in this case. > > > > Kirk > > > > On Apr 28, 2011, at 2:52 PM, Cédric Beust ♔ wrote: > > > > > > > > > > > > > > > > > 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 > > > athttp://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 > > > athttp://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.
