Wednesday, December 9, 2015
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.
at 2:37:00 PM
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.
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.
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:
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.
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.
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 into
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
at 2:36:00 PM
Every time we throw or re-throw, an exception message must describe the problem with as much detail as possible.
at 2:33:00 PM