java lambda

Edit

Joshua Bloch의 인터뷰

http://blog.jooq.org/2014/04/04/java-8-friday-the-dark-side-of-java-8/

이 글을 보니 Joshua Bloch가 과거에 말한게 생각나는데 2006년에는 아래와 같이 말했고,

2006년 : http://www.infoq.com/interviews/joshua-bloch

질문 : Where do you stand on the closures debate?

답변 : I like closures. I think they work very well in languages that design them, like Smalltalk and Scheme and so forth. I think closures in java are a good thing. We’ve basically had them since 1.1 in the form of anonymous class instances and those are a bit clunky so I definitely see a place for improvement support for closures; on the other hand some of the proposals that I’ve seen floating around are overly complex; they involve massive changes to the type system, things like function types and I’m severely worried about pushing the complexity of the language beyond the point where Joe Java can’t use the language anymore. If we add more support for closures I think it has to be in the spirit of the current support, which means that closures should take the form of instances, of types that have a single abstract method, whether they are interface types such as Runnable , or class types such as TimerTask. I think it would be nice if a better syntax in the current anonymous class syntax were adopted and if requirement with regards to Final variables were somehow made more tangible, which doesn’t mean necessarily relaxed; I think it’s actually good that you can not close over non Final variables, but it’s a pain to actually mark them final, so if they automatically marked themselves final which would be nice.

2010년 : http://www.infoq.com/interviews/josh-bloch-java-prog

질문 : One of the debates, which has been ongoing for the last several years, is that around adding closures to Java the language. What are your thoughts on that?

답변 : I think that some form of closures would be a good thing because anonymous inner classes are verbose and nobody really like them all that much. On the other hand, we have certainly seen proposals that add immensely to the conceptual surface area of the language and I’m glad that Project Lambda seems to be moving away from these overly complex solutions. I hope they come up with something nice.

질문 : Which of the variety of Lambda proposals do you think is best suited to putting into the Java language or do you think it’s one that would contain some of the capabilities of the different implementations which have been discussed?

Clearly it’s going to contain something from each of the proposals, but there are certain things that add a lot of complexity. For example, permitting local and non-local returns and forcing people to think about whether this is a local return or a non-local return. That’s a massive source of complexity. Function types is an interesting one, I was kind of resigned to seeing them in the language, although of course they do add greatly to the complexity. The most recent proposals from Project Lambda don’t include function types. We’ll see what happens there.

I think the most important thing is to make it easier to do what you can already do with anonymous inner classes, just to remove all of that needless verbosity. Another thing which I see as worse than a mixed blessing is the ability to access to close over mutable state from within Lambda expressions. Generally that causes more harm than good and I don’t mind at all if it’s outright impossible or if you have to somehow annotate (I shouldn’t say annotate but), to place some syntactic cue as to what state you wish to mutate from within a Lambda expression.

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-translation.html

JVM 실행 옵션에 -Djdk.internal.lambda.dumpProxyClasses를 주고 람다식이 있는 코드를 실행시키면 런타임시 정의한 람다 클래스를 파일로 저장해준다. 클래스 파일 위치를 지정하고 싶으면 경로를 = 뒤에 넣어줘도 된다.

http://www.slipp.net/wiki/pages/viewpage.action?pageId=19530334

https://www.facebook.com/tobyilee?fref=ts#

AOP에 응용 : http://www.slideshare.net/antoinesd/invoke-dynamite-with-invoke-dynamic

람다의 제네릭

자바에서 익명 클래스와 람다는 비슷하게 동작하지만, 런타인에 타입 인자를 참조할 수 있는지에 대해서는 차이가 있다.

익명 클래스는 실제 클래스로 컴파일되어 그 클래스의 시그니처에 직접 상속/구현하는 상위 타입의 제네릭 인자가 기록된다 자바의 제네릭(Generics)은 컴파일 타임에 타입 추론이 일어나고 런타임에는 제네릭 타입 정보가 지워지는 타입 소거(type erasure) 형태로 변환된다. 하지만 익명 클래스와 같이 클래스 시그니처에 있는 정보는 런타임에도 리플렉션을 통해 이를 얻을 수 있다. 예를 들어, var comp = new Comparator<String>() {…​} 와 같이 익명 클래스를 선언하면, 타입 파라미터에 들어간 타입 인수인 String은 리플렉션을 통해 조회할 수 있다. 닐 개프터(Neal Gafter)가 고안한 슈퍼 타입 토큰(super type token)이라는 기법이 같은 원리를 이용하고 있다. ( http://gafter.blogspot.com/2006/12/super-type-tokens.html 을 참고)

반면 람다 표현식은 익명 클래스와는 달리 타입 인자에 대한 정보를 저장할만한 공간이 없다. 따라서 람다 표현식에 의해 구현된 인터페이스가 소스에서는 타입 인지가 보인다고해도 런타임에 리플렉션으로 이를 얻는 것은 불가능하다. 예를 들어, Comparator<String> 인터페이스를 람다 표현식으로 구현할 때 Comparator<String> comp = (a, b) → a.compareTo(b); 와 같이 작성하면, 이 객체에서의 타입 인수인 String은 런타임에는 알 수 없다.

이러한 차이는 제네릭 타입 정보가 필요한 리플렉션 기반의 라이브러리나 프레임워크를 사용할 때 중요하다. 직렬화 라이브러리나 의존성 주입 프레임워크 등이 이에 해당한다. Jackson/Gson의 TypeReference/TypeToken처럼 익명 클래스로 슈퍼타입의 제네릭을 고정하는 패턴이 널리 쓰인다.