Java 9 delayed by slow progress on modularization

Oracle's Mark Reinhold has proposed a a six-month extension of the JDK 9 schedule, pushing the release to May 2017

Java 9, a major release of the standard Java platform that was planned for September 2016, is now likely to be postponed by six months.

In an openjdk mailing list post this week, Oracle's Mark Reinhold, chief architect of the Java platform group, blamed the delay on complexities in developing modularization, which improves scalability and performance and is based on Project Jigsaw. "We've made good progress on Jigsaw over the last 18 months," wrote Reinhold. But the current JDK (Java Development Kit) 9 feature complete milestone is set for December 10, and Jigsaw "needs more time."

"The JSR 376 EG (expert group) has not yet published an Early Draft Review specification, [but] the volume of interest and the high quality of the feedback received over the last two months suggests that there will be much more to come, and we want to ensure that the maintainers of the essential build tools and IDEs have adequate time to design and implement good support for modular development."

Thus, Reinhold is proposing a six-month extension of the JDK 9 schedule, postponing general availability until March 2017 and moving the feature-complete milestone to May 2016. "As with previous schedule changes, the intent here is not to open the gates to a flood of new features unrelated to Jigsaw, nor to permit the scope of existing features to grow without bound."

If no reasoned objections are raised by next Tuesday, Dec. 8, this new schedule would be adopted. The Dec. 8 deadline also holds if objections are raised and satisfactorily answered.

This is not the first time Jigsaw has been delayed. It had been slated for  inclusion in Java 8, which shipped in March 2014, but was postponed until Java 9 to give more time to work on technical issues.

This story, "Java 9 delayed by slow progress on modularization" was originally published by InfoWorld.

Up close with Google's Angular 2 JavaScript framework

Here's all you need to know about Angular 2, the exciting new successor to Google's wildly popular JavaScript framework, AngularJS

Two years ago Google promised a major rewrite of AngularJS, which back then was already topping the charts as the most popular JavaScript framework. Now the new version, dubbed Angular 2, is finally nearing a beta release.

Angular 2 draws on the perspectives of experts who have both learned from experience and have an eye toward future standards. Now’s a great time to see what the framework authors are bringing to the next version.

[ Need a JavaScript tool for your dev shop? InfoWorld looks at 17 JavaScript editors and IDEs ready for adoption. | Keep up with hot topics in programming with InfoWorld's Application Development newsletter. ]

The rise of Web Components

In AngularJS, nearly everything to control page rendering is done with directives. There are lots of existing directives ranging from the very simple (for example, ngIfis a directive you can use to conditionally show/hide part of the page) to the complex (such as data binding with ngBind). You often create your own directives to add custom behavior to an element or simply to render a template.

Angular 2 largely replaces directives with “components.” This approach looks forward to future Web Components specifications, including Shadow DOM and HTML Imports. Meanwhile, the component pattern is already showing up in many JavaScript libraries.

When you compare AngularJS’s directive approach with Angular 2's component approach side by side, they appear very similar. But conceptually, they're different:

Angular 1	Angular 2
angular.module('App', [])  .directive('example', function() {    return {      template: '<p>Some DOM content</p>'    };  });	var AppComponent = ng  .Component({    selector: 'my-app',    template: '<p>Some DOM content</p>'  })  .Class({    constructor: function () { }  });

As a standard, Web Components have some issues. Browser vendors still need to shake things out a bit for Web Components to be implemented. As an architectural component of an client-side application, however, the Web Components approach is something to be reckoned with.

Componentization within the interface allows behavior and presentation to be modularized, testable, and reusable. Furthermore, the developers of Angular 2 plan to make it compatible with Web Components created with such libraries as Polymer and X-tag so that Angular 2 will be very friendly to code reuse.

The bottom line is that, once the kinks are ironed out, you'll want to use Web Components. As it turns out, using a performant framework -- as Angular 2 intends to be -- may be one of the best ways to incorporate Web Components into your applications, while letting the framework authors and the community manage compatibility with evolving standards.

Reactive programming

Angular 2 builds on a reactive programming style using event-driven streams of data, rather than on the object-oriented approach you might see in MV* frameworks. In fact, data flow is the most interesting thing you won’t see mentioned on Angular 2's features page.

It all starts with how the framework gets its data: Promises versus Observables. Promises are a method of triggering an asynchronous action, then handling the result when it's ready. In contrast, Observables are a proposed standard type that allows subscription to a stream of values.

In his talk on data flow in Angular 2, Rob Wormald provides examples of “typeahead” functionality in AngularJS versus Angular 2, demonstrating the work required to debounce requests -- that is, to not waste HTTP requests while the user is still typing, yet still provide nearly instantaneous “typeahead” search results.

I’ve modified the code here to make it more understandable out of context. The value of this.searchResults is modified based on a typeahead field.

Angular 1

Angular 2

// change event to be fired // whenever the search box value changes // creating timeouts to debounce the request onSearchChanged() {  var searchText = this.searchText;  if(typeof this.searchTimeout !== 'number') {    clearTimeout(this.searchTimeout);    this.searchTimeout = null;  }  this.searchTimeout = setTimeout(() => {    this.doSearch(searchText);    this.searchTimeout = null;  }, 200) } doSearch(searchText) {  this.currentRequest = fetch('/someendpoint?search=${searchText}')      .then(res => res.json())      .then(results => this.searchResults = results) }

this.searchResults = Observable.from((<EventEmitter>this.searchText.valueChanges).toRx())    .debounceTime(200)    .switchMap((val:string) => myService.load(val))    .merge(this.clear.toRx().mapTo([]));

As you can see, a simple reactive action (debounceTime) is required for Angular 2 to provide the same debounce functionality as AngularJS to get values intothis.searchResults.

In order to leverage Observables and reactive actions, Angular 2 employs the next version of RxJS. That means users of Angular 2 also benefit from access to this reactive tooling (the ability to simply debounce a stream of events serving as an example), and Angular 2 users are likely provide more fuel for reactive programming champions.

Choose your own language

While AngularJS is a JavaScript framework, Angular 2 is a “whatever compiles to JavaScript” framework. As long as what you want to write in can compile to JavaScript, you can (probably) use Angular 2.

In the new Angular documentation, you’ll notice a drop-down for JavaScript, TypeScript, or Dart. While this might change (it looks like a beast of documentation work), it’s an indicator of the community’s intentions.

Angular 2 itself is written in TypeScript, a typed superset of JavaScript. You can think of it in shorthand as “ES2015 with types.” While this may give TypeScript an edge in adoption, it’s clear that the framework authors intend Angular 2 to be friendly to transpiled languages in general.

Thanks to AngularJS's popularity, adoption of Angular 2 will probably be huge. The new framework has a lot to show you regarding trends to pay attention to: JavaScript apps won’t have to be written in JavaScript (if they can make the compile target work). Reactive programming is on the rise, especially for browser apps. And the Web Components standard is sticking around -- even if the browser vendors haven't ironed out how they will support it.

This story, "Up close with Google's Angular 2 JavaScript framework" was originally published by InfoWorld.

6 Python libraries every programmer will love

Fast, safe database access; quick, clean Web frameworks, no-fuss cross-platform GUIs -- these libraries solve problems over the short term and the long haul

In programming, little frustrations can be as agonizing as the big problems. No one wants to pull their hair out merely to pop up a window with a text message or to write quickly (and safely!) to a database. But programmers would welcome fast solutions to these issues that are also robust in the long run.

Here are six Python libraries that provide quick fixes to immediate problems, but can also be used as the underpinnings for bigger projects.

[ Download InfoWorld's special report: "Extending the reach of enterprise developers." | Keep up with hot topics in programming with InfoWorld'sApplication Development newsletter. ]

Pyglet

What it is: Pyglet is cross-platform framework for multimedia and windows graphics in pure Python.

Why you need it: It provides handy access to items that are tedious to implement from scratch for a GUI application: window functions, OpenGL graphics, audio and video playback, keyboard and mouse handling, and working with image files. (It doesn't provide UI widgets like buttons, toolbars, or menus, though.)

All of this is done through the native platform capabilities in Windows, OS X, or Linux, so there are no binary dependencies; it's pure Python. It's also BSD-licensed, so it can be included in any commercial or open source project.

Peewee

What it is: Peewee is a small but powerful library for accessing databases by way of an ORM, with native support for SQLite, MySQL, and PostgreSQL.

Why you need it: Any application that uses external data in more than a trivial manner typically uses a database, but getting and setting data from a database via ad hoc connection strings is asking for trouble.

Peewee provides a safe, programmatic path to access database resources, using a set of Python classes that are intuitive for both Python developers and database engineers. With Peewee, quick-and-dirty way to access a database can be later expanded to a more robust option without having to rip it out and start over. Transactions are natively supported, and optional modules provide support for everything from connection pooling to advanced field types like many-to-many.

Bottle

What it is: Bottle is a tiny, lightweight Web framework that's also quite fast.

Why you need it: When you simply want to throw together a quick RESTful API or use the bare bones of a Web framework to build an app, Bottle gives you no more than you need. Routing, templates, access to request and response data, support for multiple server types from plain old CGI on up, and support for more advanced features like WebSockets -- it's all here.

The amount of work needed to get started is minimal, and Bottle's design is elegantly extensible for when more advanced functions have to be plugged in.

Invoke

What it is: "Pythonic remote execution" -- in plainer English, Invoke allows you to perform admin tasks using a Python library.

Why you need it: Who wouldn't want a "clean, high-level API for running shell commands and defining/organizing task functions"? Using Python as a replacement for common shell scripting tasks makes sense, and Invoke provides common-sense solutions to take command-line tasks and manage them as if they were Python functions, allowing bigger items to be elegantly built around them.

Note that Invoke's version as of this writing is considered pre-release software; if you want something guaranteed stable (if no longer being actively developed), consider Invoke's predecessor, Fabric.

Splinter

What it is: Splinter is a Python library for testing Web applications by automating interactions with them.

Why you need it: Let's face it -- little is less fun than trying to automate Web application testing. Splinter automates everything end to end, invoking the browser, passing URLs, filling out forms, clicking buttons, and so on.

It requires drivers to work with a specific browser, but Chrome and Firefox are already covered, and it can use Selenium Remote to control a browser running elsewhere. You can even manually execute JavaScript in the target browser.

Splinter is useful if you want to find out how specific browsers behave when confronted with a given website. For automating site interactions without a browser -- essentially a kind of curl on steroids -- check out Twill.

Arrow

What it is: The Arrow library sorts out the mess that is Python's date/time handling.

Why you need it: Dealing with time zones, date conversions, date formats, and all the rest are a headache and a half. With Python's standard library for date/time work, you get two headaches.

Arrow provides four big boons, all useful in the short and the long term. One, it's a drop-in replacement for Python's datetime module, meaning common function calls like .now() and .utcnow() work as expected. Two, it provides methods for common needs like shifting or converting timezones. Three, it provides "humanized" date/time information -- such as being able to say something happened "an hour ago" or will happen "in two hours" without a lot of effort. Four, it can localize date/time information without breaking a sweat.

[An earlier version of this article stated incorrectly that the Invoke library could be used to manage systems remotely by SSH.]

This story, "6 Python libraries every programmer will love" was originally published by InfoWorld.

Throwing an Exception Without Proper Context Is a Bad Habit

Every time we throw or re-throw, an exception message must describe the problem with as much detail as possible.

I keep repeating the same mistake again and again. So it's time to stop and make a rule to prevent this from happening anymore. The mistake is not fatal, but it's very annoying. When I look at production logs, I often see something like "File doesn't exist", and I ask myself: What file? Where is it supposed to exist? What did the server try to do with it? What was going on a second before it crashed? There is no answer in the log, and it's totally my fault. I either 1) don't re-throw or 2) re-throw without providing context. Both are wrong.

Four Rooms (1995) by Allison Anders et al.

This is how the code may look:

if (!file.exists()) {

  throw new IllegalArgumentException(

    "File doesn't exist"

  );

}

It may also look like this:

try {

  Files.delete(file);

} catch (IOException ex) {

  throw new IllegalArgumentException(ex);

}

Both examples demonstrate an inadequate style of handling situations that involve exceptions and reporting them. What's wrong here? The exception messages are not thorough enough. They simply don't contain any information from the place where they originated from.

This is how they should look instead:

if (!file.exists()) {

  throw new IllegalArgumentException(

    String.format(

      "User profile file %s doesn't exist",

      file.getAbsolutePath()

    )

  );

}

And the second example should look like this:

try {

  Files.delete(file);

} catch (IOException ex) {

  throw new IllegalArgumentException(

    String.format(

      "Can't delete user profile data file %s",

      file.getAbsolutePath()

    ),

    ex

  );

}

See the difference? This may look like redundant code, but it's not. Of course, when I'm writing all this, I don't really care about logs and exceptions. I'm not really expecting this file to be absent.

But I should.

There should be a rule: Every time we throw or re-throw, an exception message must describe the problem with as much detail as possible.

Of course, we can't forget about security and risk putting any sensitive information into the exception message, like passwords, credit card numbers, etc. Besides that, as much as possible must be exposed to the exception catcher at a higher level.

Throwing an exception is literally an escalation of a problem to a higher level of management. Imagine that my boss is asking me to install a new server. I come back to him in a few hours and say, "I failed; sorry." That would sound strange. He would ask for more details. Why did I fail? What exactly went wrong? Is it possible to do it differently? Etc.

Such code is literally a sign of disrespect to the client:

throw new IllegalArgumentException(

  "File doesn't exist"

);

I have to be more verbose and give more details.

And I'm not alone in this mistake. I see it everywhere, and it really makes debugging difficult, especially in production, where it's almost impossible to reproduce the problem right away.

Thus, please be more verbose in your exception messages. I will do the same in my code :)

And one more thing before you go. In most OOP languages, exceptions are unchecked, which means that catching them is not a mandatory operation, unfortunately. Nevertheless, I recommend you catch, add context, and re-throw them all, always. This may seem like pure noise, but it's not! Just make your methods smaller and ensure all exceptions sent out of them have enough information about their origins. You will do yourself and everybody else a big favor.

Published at DZone