While you were away

#AboutLastWeek: Win some, lose some — Angular 2, Java EE 8, microservices

JAXenter Editorial Team
Ripped paper with word weekly report image via Shutterstock

Each Monday we take a step back and analyze what has happened in the previous week. Last week we presented the fifth release candidate of Angular 2, we shed some light on what Java Champion Jeff Genender thinks of Java EE 8 and we launched a microservices checklist. Our first interviewee was Viktor Farcic, Senior Consultant at CloudBees. But that’s not all.

Angular 2 — Almost there

Angular 2 is coming soon, but for the moment let’s enjoy the milestones the Angular 2 team prepared for us. Last week the Angular team released release candidate number 5, which contains lots of bug fixes and features. Among the breaking changes we have the following: ApplicationRef.waitForAsyncInitializers is deprecated, so AppInitStatus.donePromise /AppInitStatus.done is now used instead. ApplicationRef.registerBootstrapListener is also deprecated, so the team advises users to provide a multi provider for the new token APP_BOOTSTRAP_LISTENER instead. See here all the core breaking changes.

TestInjector is now called TestBed:


import {TestInjector, getTestInjector} from '@angular/core/testing';


import {TestBed, getTestBed} from '@angular/core/testing';

Plus, the following API has been removed since it was never intended to be public:

import {verifyNoBrowserErrors} from '@angular/platform-browser/testing_e2e';

Here is the entire list of changes.

Java EE’s fate to be decided soon. But will Java EE 8 satisfy expectations?

Discussions about the future of Java EE persist even after Oracle’s Thomas Kurian made it clear that the company has big plans for enterprise Java. People are still skeptical about Oracle’s strategy, which will be unveiled at the JavaOne conference in September. We invited Jeff Genender, Java Champion and Apache Member, to react to the latest news and weigh in on the future of Java EE 8.

The Java Champion opined that Oracle co-founder Larry Ellison “wants more revenue from the cloud,” which is why Kurian tried to “use Java EE as a carrot to lead people in…. i.e. paying cloud customers.”

If Red Hat, IBM, and some of the other big players want to make change, they can try to step up and take leadership of the JavaEE 8 JSR, and if Oracle doesn’t play nice, just start a new JSR for a new Java EE.  Nothing would be more shocking to end users if everyone bailed out of the Java EE JSR and the only “expert” on the group was Oracle.  It would die a very quick death.  So the community has a lot of power in its direction… someone just needs to step up and run with it — but do it right.

Why are microservices important for you? (Part 1)

Last week we launched a checklist with the aim of finding out when, how and why microservices are important for our experts. In part one, we learned that Viktor Farcic, Senior Consultant at CloudBees, started using microservices out of frustration.

That frustration was generated from continuous failures to implement some of the practices I was proposing. We tried to have a good test coverage and failed. We attempted to implement continuous integration and, later on, continuous delivery, and failed. We sought to have short release cycles, and failed. We tried to create immutable deployment and failed. We decided to split the horizontal teams vertically and make them small and agile. That failed as well.

He revealed that innovation is at the top of his list of benefits because “microservices allow us to change things and experiment with new languages and frameworks. Change is the major motor behind innovation and innovation is driving change. Monoliths are too big and often too coupled to allow such freedom.” At the same time, he descibed the major challenge of microservices through Conway’s Law: “Switching to microservices architecture without changing organization will result in a failure. Ever since microservices became popular, everyone wants them, but only a few are willing to apply changes required for a successful transition. The fundamental challenge does not lie in technology but in culture.”

Stay tuned for part 2!

How Atlassian jumped on the DevOps bandwagon

Practicing DevOps in the true sense of the word may be challenging, but once you’ve overcome the obstacles and preconceptions, everything becomes easier. We asked Atlassian’s Michael Knight and Nick Wright to tell us how this company benefits from (genuinely) putting DevOps into practice.

Our DevOps culture has grown organically over time. I think this was mainly due to our existing commitment to Agile methodologies. We gradually moved from just being an off-the-shelf software vendor to also being a services provider. Our existing Agile practices like cross-functional teams, small/iterative changes with automated testing and quick feedback loops saw teams make a natural progression to a DevOps-style culture as we expanded our ops capabilities to accommodate this change.

Eager to find out how our discussion went? Read the entire interview here.

Inline Feedbacks
View all comments