Java Programming Language: Design Principles and Proposals

Link : http://java.sun.com/developer/technicalArticles/JavaLP/jpl_proposals.html

Java Programming Language: Design Principles and Proposals

By Danny Coward, August 2007

Preface In light of some of the recent discussions about potential enhancements to the Java language, there has been general concern that the Java language will get too complicated and will be filled with esoteric features that only a few people want and will use. As stewards of the Java Programming Language, we welcome such discussions and highlight some proposals here. See For More Information for links to alternate views and sources.
서언 자바 언어의 잠재적인 강화에 대한 최근의 논의들 중, 자바가 너무 복잡하고 오직 소수의 사람들만이 원하고 사용하게될 난해한 특징들로 채워질 것이라는 일반적인 우려가 있어왔다. 자바 프로그래밍 언어의 관리자적 입장에서 우리는 그러한 견해를 반기고 여기서 몇가지 제안들을 조명해볼 것이다. 다른 대안적인 견해와 자료는 For More Information 를 참조하기 바란다.

Curling the Chip 감자칩 구부리기

There was an excellent story in The Economist a few years ago about innovation. One of the points was to contrast innovation in new products and in established products. A wholly new product has no customer base, no commitments or expectations. So successful innovations tend to be big new ideas, or a disruptive application of an old idea in a totally new setting, like the Sony Walkman was.

몇년 전 이코노미스트지에서 혁신에 관한 뛰어난 얘기를 다뤘다. 그 중 하나는 새로운 제품과 기존의 제품에서 혁신의 차이점에 대한 것이었다. 완전히 새로 만들어지는 제품들은 기존의 고객층이나 헌신, 또는 기대치도 없다. 따라서 성공적인 혁신은 아주 새로운 아이디어에서 비롯되거나 과거의 아이디어를 완전히 새로운 환경하에서 창조적으로 적용하는데에서 온다.

Innovation for established products is arguably more difficult: You have customers who already like your product who you want to keep. There are teams of people building, delivering, and selling your product that would be difficult or expensive to change. So your ability to innovate is much more constrained.

기존의 제품들에 대한 혁신은, 다소 차이는 있지만 보통 더욱 어렵다. 그 제품을 좋아하는, 회사 입장에서는 꼭 붙잡아두고 싶은, 고객들이 이미 존재하고 있다. 그 제품을 만들고 유통하고 판매하는, 변화를 가져오기 어렵고 비용이 많이드는 여러 조직들도 있다. 따라서 혁신 역량은 더욱더 제약될 수 밖에 없다.

But the article described the example of a company making potato chips that were popular, but not popular enough. Rather than invent some wholly new potato-based snack, they put a curl at the end of each chip. There was minimal disruption to their production processes. Customers didn't notice anything new until they opened the bag. There are two happy endings depending on your perspective: people loved eating them because they could shovel more dip onto them; people loved serving them because there was less spillage of dip after the party was over. Either way, sales jumped dramatically.

그러나 기사에서는 아주 유명하진 않지만 어느정도 알려져있던 감자칩 제조 회사의 일례를 다루었다. 완전히 새로운 감자 스낵을 만드는 대신에 그 회사는 감자칩의 끝을 약간 구부린 것이다. 생산 과정에 약간의 변화가 있었다. 고객들은 봉지를 열때까지는 뭐가 달라진건지 알지 못했다. 사람들의 입장에 따라서 두가지 해피 엔딩이 있다. 첫번째로, 사람들이 이 과자를 즐겨먹었는데 과자 끝이 약간 구부러져서 더 많은 양념을 떠올릴 수 있었다. 두번째로, 사람들이 이 과자를 파티에 내놓는걸 좋아했는데 파티가 끝난 후에도 양념이 그다지 많이 흘려져 있지 않았기 때문이다. 과자 판매는 극적으로 치솟았다.

So, to some extent, with a successful technology like the Java Platform, Standard Edition (Java SE), we need to scan the horizon for the metaphorical curls in the chip - non-disruptive innovations that have widespread useful consequences. Given that many Java developers are Java Platform, Enterprise Edition (Java EE) developers, for example, it is no wonder that the use of annotations has been such a big hit. That curl in the chip has helped scoop up a big wobbling dollop of complexity out of the Java EE deployment descriptors and programming model.

자바 플랫폼같은 성공적인 기술에서도 감차칩 구부리기와 같이 근본적으로 변화를 도모하지 않고도 좋은 결과를 낼 수 있는 혁신에 대한 시야를 가질 필요가 있다.  예를 들어 많은 자바 개발자들이 엔터프라이즈 자바 개발자들이라고 했을때 어노테이션의 사용이 큰 히트를 친 것은 이상한 일이 아니다. 감자칩을 약간 구부리는 변화로 자바 EE 개발 기술과 프로그래밍 모델에서 덜렁덜렁 흔들리는 커다란 복잡도 덩어리를 떠올릴 수 있게끔 해준 것이다.

Principles for Evolving the Java Language

Have you ever wondered why some cars are instantly recognizable? Seen a new BMW in the last 25 years without twin headlamps? Wondered how an SUV can still look like it's a Porsche? How a Corvette can still convey "Corvette" after over 50 die-hard years?

여러분들이 어떤 차들을 봤을때 즉각 알아볼 수 있는 이유가 뭔지 궁금해본 적은 없는가? 지난 25년간 쌍전조등이 아닌 새로운 BMW 를 본적이 있는가? SUV가 여전히 포르쉐처럼 보일 수 있는지 궁금한 적은? 어떻게 콜벳(차 이름)이 50년이 넘게 콜벳으로 존재해올 수 있었을까?

Car designers, of course, follow certain design principles that keep the look of cars, especially their luxury brands, distinctive across multiple evolutions of a successful model. While we may not be aware of what these principles are as we see a new model Volvo pass us on the freeway, we usually know its a Volvo before we can explain why.

특히 고급 차종일 경우는 더욱 그러한데 성공적인 모델의 여러가지 변종간에 명확한 구별을 위해서 차 디자이너들은 차의 외양을 유지하는 어떤 디자원 원칙을 따른다. 반면에 고속도로에서 신형 모델의 볼보를 볼때 이런 원칙을 알아채지는 못해도 우리는그 차가 볼보라는걸 안다.

So what is it about code written for Java SE 5.0 - the release where we evolved the language in several ways - that makes it recognizable as the "same" Java you knew in JDK 1.2? (Only with some special sauce added.)

그러면 우리가 알고 있던 JDK 1.2에서의 자바와 언어에 몇가지 진화를 가져온 자바 SE 5.0 을 구별짓게하는, 이것이 무엇인가?

Just like the twin headlamps of BMW cars, the original design team and successive teams have followed certain design principles for the creation and evolution of the Java language.

BMW의 쌍전조등의 경우처럼 원조 디자인팀과 이를 계승하는 팀들은 자바 언어의 창조와 진화를 위해서 어떤 디자인 원칙을 따라왔다.

Reading is more important than writing

One of the principal tenets is that it should do what you would expect it to do. There may be some developers who manage to produce fully formed and perfect code, ideally written for any future circumstance. When they are not walking on water, I guess. But for the majority of us, code is something living that we (or someone else) will need to revisit many times in what we hope to be a long and productive life.

주요한 원칙 중 하나는 사람들이 그러하리라고 생각하는대로 작동해야한다는 것이다. 미래의 어떠한 상황에도 대처할 수 있는 이상적이고 완벽한 코드를 작성해놓는 개발자들도 더러는 있을 것이다. 뭐 때로는 그런 기적을 행하지 못할때도 있겠지만 말이다. 하지만 우리 대다수들에게 코드는 여러번 들여다볼 필요가 있는, 살아있는 무언가이다.

One language, with the same meaning everywhere

No flavors, dialects, slangs, pidgins, or creoles allowed! One of the chief advantages of the Java language is that whether it be written as part of an applet or a desktop application, or to run an algorithm on the world's largest search engine, it still means the same thing.

자바 언어의 최고 장점중 하나라면 애플릿이든 데스크탑 애플리케이션이든, 또는 세상에서 가장 큰 검색 엔진의 알고리즘을 실행하기 위해서 작성되었든 모두 똑같은 의미를 갖는 동일한 코드라는 점이다.

Simplicity matters 단순함이 관건이다

If the semantic model of a language is clear - if its rules are simple and precise - the language will be more productive to use. Less is more. Naturally, this creates an instant tension when considering a new language feature: Adding a feature is in itself a new complexity in the overall scheme of things. Something new to understand, something new to trip over, to waste an afternoon on.

언어의 의미 모델이 명확하다면, 그러니까 언어의 규칙이 단순하고 정확하다면 그 언어는 더욱 생산력이 있을 것이다. 적을수록 낫다는 말이 있다. 물론 언어에 새로운 특성이 주입되는 것을 고려해보면 이는 즉각적인 긴장을 일으킨다. 하나의 특징을 추가하는 그자체는 대상의 전체적인 구성에 새로운 복잡도이다. 이해할 새로운 어떤 것, 삽질을 할 어떤 것, 오후 내내 시간낭비할 어떤 것.

Over the course of a number of generations of evolution, you may see the link between only one generation and the next. A car's 2006 model may bear little visual relationship with the 1990 model. You only need look at C++ with its surfeit of features, each added no doubt for excellent reasons individually but collectively adding up to a big old heap of complexity. It was evolving under a different design principle ("more is less"?) before its Java-like successor (C#) appeared on the scene.

수많은 세대에 걸친 진화의 과정속에서 여러분은 오직 한 세대에서 그 다음 세대간의 관련성만 보기 마련이다. 자동차의 2006년 모델은 1990년식 모델과 겉보기에 아무런 관련이 없어보일지 모른다. 여러분들은 오직 C++의 넌더리날 정도로 많은 특징들과 함께 C++를 본다. 그 특징들 하나하나는 모두 의심할 여지가 없는 훌륭한 근거를 가지고 C++에 포함된 것들이지만 모두 모아놓고 보면 커다랗고 복잡한 덩어리이다. C++는 자바와 같은 후계자(C#)들이 전면에 나타나기 전부터 다른 디자인 원칙 하에서 진화해왔다.("많을수록 별로다?").

Changing Demographics

Of course, since Java's first release, the world has changed. In 1995, the predominant language that developers learned was C. In wrapping high-power concepts like garbage collection, object orientation, and concurrency into a language with a C-like syntax, Java managed to appeal strongly to C developers. But in 2007, such concepts have become so "last decade" (ironically, as in fact they originated with flared trousers and predate the war between Betamax and VHS). A new generation of developers has started with Java, rather than ending up there. One of the many interesting challenges for the Java language is how much to appeal to developers who additionally experiment with new dynamic languages like Python or Ruby, without having Java turn into a compromised superset of all of them.

물론 자바의 첫번째 배포판 이래로 세상은 변했다. 1995년 당시 개발자들이 배우고 익힌 주류 언어는 C였다. garbage collection, 객체 상속, 동시성과 같은 막강한 개념들을 C와 같은 문법으로 포장하는데 있어서 자바는 C 개발자들에게 그런대로 강한 호소력이 있었다. 그러나 2007년인 지금, 그러한 개념들은 "지난 10년의 것"이 되어버렸다. 새로운 개발자 세대는 거기서 끝나지 않고 (?) 자바와 함께 시작했다. 자바에 대한 흥미로운 도전들중 하나는 파이썬이나 루비같은 언어들의 특징들마저 포함하도록 자바를 바꾸지 않으면서 그런 새로운 동적 언어들을 가지고 실험하는 개발자들에게 큰 호소력을 갖는 방법이다.

A factor in the Java language's longevity will be the relevance of the design principles we use to evolve it. If we choose wisely, these will keep us classic and yet hip for a long time to come.

자바 언어의 장수 요인중 하나는 자바를 진화시키기 위해서 사용한 디자인 원칙의 타당성일 것이다. 우리가 현명하게 선택한다면 이런 원칙들을 통해서 우리는 고풍스러우면서도 다가올 오랜시간동안 여전히 유행에 뒤떨어지지 않을 것이다.

Many Potential Enhancements

Over the years we have accumulated a large number of proposals for enhancements to the Java language. It is a fascinating task for the team here at Sun to work through the proposals and see how, both taking the proposals individually and in combination, they could continue to make the Java language productive and desirable to learn. Over the coming months, we hope to bring a proposal to the Java Community Process, but for now let's just highlight a small number.

몇해에 걸쳐 우리는 자바 언어를 강화하기 위한 수많은 제안들을 축적해왔다. 여기 Sun에서 팀들이 그런 제안들을 접하면서 어떻게 그런 제안들이 자바를 생산적이고 배우기에 바람직한 언어로 만들 것인지, 제안들을 개별적으로, 결합해서, 살펴보는 것은 매력적인 작업이다. 앞으로 몇달간 우리는 the Java Community Process에 제안이 오기를 바란다. 그러나 이제 몇가지 제안들을 조명해보자.

Property support

The Java Beans property pattern has become a common programming practice for developers in a wide range of applications, from desktop applications, to EJB and web service components. There is a wide range of proposals to provide language support to streamline this design pattern.

Closures, Block Constructs, Method References

One of the hottest topics in recent years has been around adding full closure support to the Java language. Some have argued this is a natural and powerful extension to the language, while others have put forward other proposals that tidy up the syntax of the existing inner classes, and allow some limited extension of Java block statement, or allow for easy method callbacks.

Operator Overloading Related Ones

Just as hot a topic since the early days of developing the language has been that of allowing developers to provide custom implementations of the primitive operators in the Java language. There is a range of proposals from the hands-free, no-holds-barred ability to define the behaviors of operators operating on developer-created Java types, to more modest proposals to allow a limited form of overloading for classes like BigDecimal, or that allow the use of the array access operator on Java collections, or even allow the comparison operators to operate on Enums.

Grab Bag of Miscellaneous Items

Aside from the more high concept proposals, there are smaller changes that often derive from developers who simply find that there is something they thought would work with an existing feature, and that doesn't. Such proposals include the ability to use strings in switch statements, multiple annotations, and so on.

We carefully track language requests in the bug database.

See For Yourself

Some of you may find that language discussions quickly become too abstract and esoterical. Luckily for those of you who would rather roll up your sleeves and try it out, we have set up a new project on java.net called the Kitchen Sink Language. The goal of this project is to provide experimental implementations of a large number of language proposals, in the form of experimental compiler builds and sample code. We plan to use this project as a way of getting the proof in the pudding before we have to eat it and bake it into the platform forevermore.

Go check it out!

Classic, Yet Hip

The Latin scholars reading will already know that Eadem Mutata Resurgo means "I shall arise the same, though changed". For Java SE 7, we are pursuing a small package of language additions that will continue the tradition of enhancing the Java language, while leaving its essence intact. We hope you'll enjoy using it as much as we enjoy creating it.

For More Information

The Language Debate, by James Gosling
Kitchen Sink Language project
Kitchen Sink Language is open for business, by Peter Ahe
Bug Database
Closures for Java, by Neal Gafter
Closures for the Java Programming Language, by Neal Gafter
Concise Instance Creation Expressions: Closures without Complexity, by Bob Lee, Doug Lea, and Josh Bloch
Java SE home page
Java Tutorials: Learning the Java Language
The Java Language Specification

About the Author

Danny Coward is the Platform Lead for Java SE and Sun's Java SE/EE representative on the Executive Committee for the Java Community Process. Thanks to Sun's Spec lead, Java Language and VM, Alex Buckley for his assistance.