Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Alex Blewitt on Sep 09, 2011
One of the most anticipated new features of Java 8 is the introduction of Lambdas, which are anonymous functions that can be passed around like data in arguments and variables. However, the syntax for these wasn't widely decided, with polls asking for input on what would be most familiar to others.
A recent posting on the lambda-dev mailing list announced the conclusion that the Java Lambda syntax will be based on C# syntax. This is already widely known and used (as C# had delegates back in 1.0, support for delegate functions in 2.0 and lambda expressions in 3.0).
Other alternatives were available (such as BGGA) but the response to the survey suggested that there wasn't a huge advantage of one over the other; in addition, the pre-existing experiences of those using C# and Scala mean that there are likely to be many more programmers familiar with the general type of syntax. (The key difference between the C# and the Scala style of anonymous function is with how arguments are typed; C# uses “int foo” whilst Scala uses “foo: int” – a difference that will be fairly easy to move between. Java will adopt C#'s style of “int foo” in deference to the way types are represented in Java.)
Despite extensive searching, there was no clear winner among the alternatives (each form had some good aspects and some really not very good aspects, and there was no form that was clearly better than the others). So, we felt that it was better to choose something that has already been shown to work well in the two languages that are most like Java – C# and Scala – rather than to invent something new.
Both expressions and blocks will be permitted. An expression is represented without the curly braces {} and will, when evaluated, return the result. Blocks of statements are surrounded with {} and will not return a result unless the return keyword is used. The examples given in the mail are:
x => x + 1
(x) => x + 1
(int x) => x + 1
(int x, int y) => x + y
(x, y) => x + y
(x, y) => { System.out.printf("%d + %d = %d%n", x, y, x+y); }
() => { System.out.println("I am a Runnable"); }
One key advantage of the lambda expressions is that they will infer the types of the arguments if not specified. In some cases, the compiler may not be able to infer the correct types (especially in the case of overloaded operators; the “(x,y) => x+y” is highly unlikely to compile if Java doesn't know whether the x and y are long or double (or even Object). In most cases the type inference engine is likely to generate the correct code, although if further assistance is needed then the developer can always explicitly add the typing information.
A compiler which understands the new syntax will be made available in the near future for experimentation purposes.
Automating Error Reporting for .NET Applications
RDBMS to NoSQL: Managing the Transition
Combining Inspections, Static Analysis, Testing to Achieve >95% Defect Removal Efficiency
Introducing SQLFire: a memory-optimized, high performance SQL database
VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface
Great! Java builds on the shoulders of giants (C## and the little giant Scala). :-)
Maybe they can also acknowledge the debt owed to Smalltalk while they are at it.
Curiously, a Smalltalk like language may be coming back as "Dart" from Google:
gotocon.com/aarhus-2011/presentation/Opening%20...
We seriously have to wonder if this "Dart" thing is for real. I say tread with caution.
Ey! Thanks for the link about Dart! It would be amazing if those guys make a Smalltalk like language sponsored by Google.
(coming from the smalltalk world, I know that the Self VM had wonderful things and the blog of Gilad Bracha about Newspeak always have interesting posts about programming languages and modularity)
Actually, the Newspeak-to-ECMAScript compiler has been "almost finished" for quite a while now. I suspect Dart is related to that, maybe a slightly modified version or a subset of Newspeak that is easier to compile to ECMAScript than the extremely dynamic and reflective "proper" Newspeak.
Newspeak has been designed from day 1 to be a web programming language, or rather to be the programming language for the next evolution of the web (one could even say that Newspeak was designed to be the next evolution of the web), so it would make sense. Even if you don't actually use all the cool revolutionary features of the full Newspeak system (which would be quite hard anyway, since they haven't been implemented yet :-) ), Newspeak is still a very nice object-oriented dynamic language with software-engineering capabilities far beyond those of your typical "scripting" languages (including Smalltalk), e.g. a proper module system. Plus, a very nice actor system (and web programming is basically always distributed, asynchronous programming which is exactly what actors do well) and powerful pattern matching (which, again, is a big part of what many web apps do).
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
5 comments
Watch Thread Reply