Sunday, 24 January 2016
Tuesday, 19 January 2016
Java 9: Early look at Module system
Programming with modularity and Project Jigsaw. A Tutorial Using the Latest Early Access Build
Sander Mak: The Java Module system: a first look
Sander Mak: The Java Module system: a first look
A module system for Java has been a long time coming. Late 2014, a new JSR requirements document (JSR-376) was created to this end. The changes are slated for Java 9. However, no working prototype was available. Until yesterday, that is. There now is an OpenJDK early access build that includes Project Jigsaw.
Together with my co-worker Paul Bakker I gave a talk on the proposed Java Module system at JavaZone yesterday. We had to base this entirely on the JSR-376 requirements document and other tidbits of information floating around. While proposing this talk at the beginning of the year, we definitely thought a prototype would be available to showcase. However, that didn't quite pan out the way we thought. Instead, the prototype was released just hours after our talk ended (phew). Which means some things we say in the talk are already outdated, but the main ideas still stand. If you're completely new to the Java Module system proposal, I recommend you watch our talk before reading on. It explains the current proposal and puts it in a broader context by comparing it to OSGi.
Why modules?
So what are modules, and why do we want them? If you want an in-depth discussion, read the'State of the module system' or watch our talk. For the uninitiated, here's the Cliff's notes version.
Java has jar files. But really, these are just glorified zip-files containing classes which in turn are inside packages. When you assemble and run an application consisting of different jar files (read: every non-trivial application), you put them on the classpath. And then hope for the best. Because there's no way to tell if you put everything on the classpath that your application needs. Or whether you inadvertently put the same classes (in different jars) on the classpath. Classpath-hell (analogous to DLL-hell) is a real thing. This leads to bad situations rearing their ugly head at runtime. Also, the knowledge that a class was ever in a jar file is lost at runtime. The JRE just sees one big collection of classes. But jars need other jars. It's just not encoded explicitly in any form of meta-data at the moment. Ideally, you would also be able to hide implementation classes inside your jar and only expose your public API. The proposed module system for Java aims to solve these issues:
- modules become first-class citizens that can encapsulate implementation details and expose only what is needed
- modules explicitly describe what they offer, and what they need (dependencies), hence dependencies can be verified and resolved automatically during all phases of development
Having such a module system greatly improves maintainability, reliability and security of large systems. Not in the least of the JDK itself. Given such a system, a module graph can be automatically constructed. This graph contains only the necessary modules to run your application.
Installing JDK9 early access
If you want to follow along with the example code yourself, you need to install the JDK9 early access build that includes the Jigsaw prototype. On OSX, this means extracting the archive, and moving the extracted directory to
/Library/Java/JavaVirtualMachines/. Then, you need to adjust your path and JAVA_HOME environment variable to point to the JDK9 directory. I'm using the excellent setjdk bash script to switch between Java installations on the command line. You most certainly don't want to use this early access build as your daily Java installation. You can verify that the installation works by executing java -version. The output should read something like:java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-jigsaw-nightly-h3337-20150908-b80)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-jigsaw-nightly-h3337-20150908-b80, mixed mode)
As long as it includes the phrase Jigsaw, you're good to go. The resulting code for the example coming up can found at https://github.com/sandermak/jigsaw-firstlook.
Monday, 18 January 2016
Cloud Computing / Openstack links
The Guardian goes all-in on AWS public cloud after OpenStack 'disaster’
Apex Serverless architecture with AWS Lambda
Lessons Learned About Cloud Migration
The future of cloud computing
Cloud computing is a portmanteau term encompassing everything from infrastructure as a service (essentially renting someone else’s server equipment) through to software as a service (typically websites that someone else runs for you). In the middle, there is a platform tier providing the microservices that power the likes of Android and iPhone apps, and also many web-delivered services.
Monday, 11 January 2016
Microservices links
The Power, Patterns, and Pains of Microservices
A full-throated advocate of winning knows that the one constant in business is change. The winners in today's ecosystem learned this early and quickly.
One such example is Amazon. They realized early on that they were spending entirely too much time specifying and clarifying servers and infrastructure with operations instead of deploying working software. They collapsed the divide and created what we now know as Amazon Web Services (AWS). AWS provides a set of well-known primitives, a cloud , that any developer can use to deploy software faster. Indeed, the crux of the DevOps movement is about breaking down the invisible wall between what we knew as developers and operations to remove the cost of this back-and-forth.
Another company that realized this is Netflix. They realized that while their developers were using TDD and agile methodologies, work spent far too long in queue, flowing from isolated workstations—product management, UX, developers, QA, various admins, etc.—until finally it was deployed into production. While each workstation may have processed its work efficiently, the clock time associated with all the queueing meant that it could sometimes be weeks (or, gulp , more!) to get software into production.
In 2009, Netflix moved to what they described as the cloud-native architecture . They decomposed their applications and teams in terms of features; small (small enough to be fed with two pizza-boxes !) collocated teams of product managers, UX, developers, administrators, etc., tasked with delivering one feature or one independently useful product. Because each team delivered a set of free-standing services and applications, individual teams could iterate and deliver as their use cases and business drivers required, independently of each other. What were in-process method invocations became independently deployed network services.
Microservices, done correctly, hack Conway's law and refactor organizations to optimize for the continuous and safe delivery of small, independently useful software to customers. Independently deployed software can be more readily scaled at runtime. Independently deployed software formalizes service boundaries and domain models; domain models are forced to be internally consistent, something Dr. Eric Evans refers to as a bounded context in his epic tome, Domain Driven Design .
Independent deployability implies agility but also implies complexity; as soon as network hops are involved you have a distributed systems problem!
Sunday, 10 January 2016
Tuesday, 5 January 2016
Vert.x links
ECMAScript 6/7 on the JVM with TypeScript and Vert.x
Following the latest releases of Vert.x 3.2 and vertx-lang-typescript 1.1.0 I figured it would be a good idea to give you a couple of examples how teaming Vert.x and TypeScript helps you use ECMAScript 6 and 7 features on the JVM today.
The vertx-lang-typescript library adds TypeScript support to Vert.x 3. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. It supports the ECMAScript 6 (ECMAScript 2015, ES6) standard and also a few parts of ECMAScript 7 (ES7) already.
The library automatically compiles Vert.x verticles written in TypeScript to JavaScript and executes them on the JVM. vertx-lang-typescript also provides type definitions for the Vert.x JavaScript API. Use them in your favourite TypeScript editor/IDE to get auto-completion, API documentation and meaningful error messages.
Vert.x is a reactive, microservices toolkit for the JVM, that provides an asynchronous, scalable, concurrent services development model. It supports polyglot language development with first class support for JavaScript, Ruby, Groovy, Scala, and of course Java.
InfoQ got a chance to catch up with Tim Fox, the creators of Vert.x and the Vert.x lead architect to get his thoughts on Vert.x in general and the upcoming Vert.x 3 release.
Tim explains how Vert.x compares to Java EE, Spring, Akka, and explains how Vert.x is a good fit for microservices, reactive development.
InfoQ: What is Vert.x and why would someone pick it instead of a traditional Java stacks like Servlets or Java EE or Spring?Tim: Vert.x is a toolkit for writing polyglot reactive applications on the JVM. Unlike the traditional stacks its been designed from day one with microservices in mind, and it's also been designed with scalability in mind so it's almost completely non blocking (OS threads).
This is critical for many modern applications that need to handle a lot of concurrency - e.g. process a lot of messages or events, or handle a lot of connections.
Also, unlike the traditional Java stacks, Vert.x supports other languages than Java - e.g. JS, Ruby and Groovy so we don't force you to always use Java and can use the best language for the job at hand or for the skill-set of your team.
Another important point is that Vert.x is toolkit, not a container or "framework". That means you can use it within your existing application to give it the Vert.x super powers. For example you can use it within your Spring application, and many users do.
NY Times: Gizmo Microservice Toolkit for GoLang
Introducing Gizmo
At The New York Times, our development teams have been adopting the Go programming language over the last three years to build better back-end services. In the past I’ve written about using Go for Elastic MapReduce streaming. I’ve also talked about using Go at GothamGo for news analysis and to improve our email and alert systems at the Golang NYC Meetup. We use Go for a wide variety of tasks, but the most common use throughout the company is for building JSON APIs.
When we first began building APIs with Go, we didn’t use any frameworks or shared interfaces. This meant that they varied from team to team and project to project with regard to structure, naming conventions and third-party tools. As we started building more and more APIs, the pains of microservices started to become apparent.
Around the time we reached this point, I came across Peter Bourgon’s talk from FOSDEM 2015, “Go and the Modern Enterprise,” and its accompanying blog post. A lot of what Peter said hit close to home for me and seemed very relevant to our situation at The Times. His description of the “Modern Enterprise” fit our technology teams quite well. We’re a consumer-focused company whose engineering group has more than doubled in size to a few hundred heads in recent years, and we have had a service-oriented architecture for a long time. We have also run into the same problems he brought up. As the need for more and more microservices arose, we needed a common set of tools to orchestrate and monitor them, as well as a common set of patterns and interfaces that enable developers to concentrate on business problems. An RFC for a new toolkit named “Go Kit” came out of the talk, and eventually open source development of it was under way.
Peter’s talk and the concept of Go Kit made me very excited but also somewhat dismayed. I knew a lot of the RPC and tracing technology involved would likely take a long time to be adopted throughout the company without some stepping stones to get us there. We also didn’t have a whole lot of time to wait around for the toolkit to be completed, so we decided to build our own set of tools that could bridge the gap and hopefully complement Go Kit by implementingsome of its “non-goals.”
It’s my pleasure to announce that as of today our toolkit, Gizmo, is open source. Gizmo offers four packages to help developers quickly configure and build microservice APIs and pubsub daemons.
Subscribe to:
Posts (Atom)