Happy 8th Birthday Java!

It's been another longer journey but yesterday, exactly two years, seven months, and eighteen days after the release of Java 7 we now have production-ready builds of Java 8 available for download! This new major release contains several new features and enhancements that increase the performance of existing applications, make it easier to develop applications for modern platforms, and increase maintainability of code. Here is a brief overview about my personal highlights.

What's new overall?
Several areas of the language itself, profiles, security, JavaFX, tooling, scripting, Date and Time, concurrency and a more or less lengthy list of things changed or got added. More than 8.000 bugs and features have been addressed and be incorporated into this release. The complete list can be found in the official release-notes.

Java Mission Control 5.3
One of the highlights is the new Java Mission Control release. It is bundled with the JDK and comes with a separate list of enhancements in it's own release-notes. Find the complete documentation as part of the official Java SE 8 documentation.

Compact Profiles
The newly introduced profiles enable reduced memory footprint for applications that do not require the entire Java platform. The javac compiler has a -profile option, which allows the application to be compiled using one of the supported profiles. The three are additive layers, so that each Profile contains all of the APIs in profiles smaller than itself. The compact profiles feature is useful in small devices with less hardware power.
And yes, I am personally still totally frustrated that Jigsaw will probably never see the light. But I am happy to be proven wrong on that.

Java Date-Time Packages
Thank you Stephen! Thank you for this great piece of work. TimesTen is the new Date and Time API in Java 8. Clear, Fluent, Immutable, Extensible. There are two basic ways to represent time. One way represents time in human terms, referred to as human time, such as year, month, day, hour, minute and second. The other way, machine time, measures time continuously along a timeline from an origin, called the epoch, in nanosecond resolution. See the official tutorial for more examples and usages.

Good Bye PermGen!
Removal of PermGen. Full stop. It's gone! YES!

Security Enhancements
More and stronger Algorithms, TLS 1.2 default and further enhancements.

Nashorn
Java 8 is co-bundled with the Nashorn, which is an implementation of the ECMAScript Edition 5.1 Language Specification. See the user-guide for all the details.

Happy 8th Birthday Java!
Congratulations to everybody involved. Especially the Adopt-OpenJDK community which was driven by the London-Java-Community and supported the Date-Time efforts by providing tests.

Veröffentlicht in Java |

JavaOne CfP 2014 – Open for Business

This time of the year. Finally. It was about time. The 2014 JavaOne Call-For-Papers opened a few days back. And it is going to be a great one. Plenty of changes upcoming and it will have a huge focus on community speakers.

The rolling acceptance process from last year is back, so submit early!

A quote of mine sneaked into the advertising emails ;)
There is a new dedicated track for Agile development this year, making a total of nine Java tracks.  This year's tracks are:

• Clients and UI
• Core Java Platform
• Internet of Things
• Java Virtual Machine Languages
• Java and Security
• Tools and Techniques
• Server-Side Java
• Java in the Cloud
• Agile Development

The call for papers closes April 15th at 11:59 p.m. PDT  and there is no time to waste. The best of the best speakers from the Java/JVM ecosystem will be there and if you look at the submissions from 2012 you see that most of the content comes from the community. As usual, speakers will receive a complimentary pass to JavaOne with an accepted talk.
Go ahead and submit some awesome talks!

Abandon Fish! Migrating from GlassFish to JBoss or TomEE

I'v been a bit busy lately writing and reviewing stuff and didn't really had the chance to wrap up content for my blog. But things will change again and I am truly looking forward to that. So this is just a small reminder about one of the latest things I've been working on. RebelLabs published their latest report yesterday and it was my pleasure to put some efforts into it.

Since a while the GlassFish community is a bit uncertain about the future of GlassFish and many developers are looking into alternatives. There are plenty of recommendations backed by vendors and evangelists. And nobody looked into the details and problem areas. It was time to change that and a bunch of people put together their thoughts and experiences about what it takes and which would be the best migration target. The outcome is the Abandon Fish! report. You can get it for free (at least for the price of your email if you want the PDF) and it contains all about the history of GlassFish, an assessment of the political situation and influencing parameters and a solid analysis about the different containers and reference implementations used on different servers. The outcome are 34 pages, beautifully designed and easy to read which guide you through the first steps and give you very good hints on what to expect when trying to migrate your existing applications from GlassFish to WildFly or TomEE.


"Continuous Enterprise Development in Java" by Andrew Lee Rubinger and Aslak Knutsen

I've been doing book reviews since some time now. But this is a special one. Back at JavaOne I ran into Aslak and Andrew and we had a chance to talk about their latest book project which has been floating around the interwebs since some time now.

Abstract
Take a use-case approach to Enterprise Java development, and discover how to program more effectively. This practical book shows you how to perform continuous development, using a testing platform the authors built with the JBoss community. Known as Arquillian, this platform acts as the missing link between testing and development.

Andrew Lee Rubinger and Aslak Knutsen demonstrate how testing is the very foundation of development—essential for learning and critical for ensuring that code is consumable, complete, and correct. Whether you’re learning a new technology, debugging broken behavior, or laying down new code, Arquillian helps you document your project in the form of test cases.

Book: Continuous Enterprise Development in Java
Language: English
Paperback: 222 pages
Release Date: February 20, 2014
ISBN-10: 1-4493-2829-6
ISBN-13: 978-1-4493-2829-0


My Interview
Thanks for taking the time talking to me. We know each other since a while mostly from the Arquillian Project. It was the first to have a ton of documentation beside the awesome testing features.
Now you are writing a book "Continuous Enterprise Development in Java" which is about testable solutions with Arquillian. Let me ask you some questions about it.

What is the book all about? Putting guides together? What was your motivation?

In building out the Arquillian Test Platform, we set out to make full-scale integration testing approach the simplicity offered by unit tests.  Historically, Enterprise Java has been cumbersome to validate in what we call a “real” runtime: one that closely mirrors how it will run in production.  Spring and Java EE both offer POJO programming models which facilitate the re-use of our business objects outside a backing container, but we feel strongly that testing outside of the proper context can lead to misleading results.  Only when we plug everything in together can we be assured that things are working properly, and that applies to both the code you write *and* the code you rely upon from an application server.
As our community grew we continued to build out extensions and guides for Arquillian which would offer instruction not just in applying Arquillian tests to Java EE, but explaining some ways to piece together Enterprise Java applications as a whole.  While there are plenty of books about a single technology - Andrew has written a revision of “EJB 3.1” from O’Reilly, for example - we found that our users were coming to us to learn about Java EE in general.  This grew our mindset that “testing is development”, and the book is a natural extension of the guides we’d built off for Arquillian.
In short, we felt that there wasn’t a book which broke down a complex Java application into layers and explained how they were wired together and tested, so we wrote one.

You're using a comprehensive example app throughout the book. What is GeekSeek all about and why did you choose it?

From the onset, we knew we wanted our examples to be more than simple toys.  We wanted to address the concerns of a developer charged with delivering a complete application: how do you validate asynchronous components?  What’s a good way to expose a true RESTful interface for your services?  How may a UI call the services layer and how do we ensure the rendered response is correct?  How do alternative domain models factor into the equation; should they be used and if so, when?

So we needed some single application which would allow us to address the use cases we wanted to explore without feeling like we were overengineering for the sake of example.  It turns out that the excellent Lanyrd service, one we use to track our own conference involvement, provided many of the features we needed to cover, so we created the GeekSeek example application as an homage of sorts to Lanyrd.

It was extremely important to us to deliver a self-proving example: one that could be downloaded and built by a user, but also ran in our own continuous integration environment and lived on a production server, so GeekSeek is the manifestation of that idea.  As developers we learn by doing, and this application is proven to work by nature of its being served up live.

Did the book help improve Arquillian? It is the best kind of "eat-your-own-dog-food" ... did you find stuff, that needs to be fixed while writing about best practices? Any war-stories to tell?

To be honest, we didn’t end up coming across too many issues with Arquillian by writing this book or GeekSeek; we’d waited until ARQ had reached a level of maturity before embarking on a large project to document its use in practice.  We did, however, encounter a series of known limitations, for instance the lack of Suite support, in writing.  Most of these issues haven’t yet been addressed because they’d require API changes in Arquillian which would break backwards-compatibility, and we have them on deck for a major version 2.0 when the time is right.

One bit I found particularly interesting is the idea of a Modular Test Suite. E.g. Module X adds Feature A to the app.  Now it’s possible Module Y is affected by these features on a test level. Why can’t Module X provide a Test Module to help Module Y? Security is a good example. Module Y doesn’t know about security, but if the Security Module is included, Module Y’s test suite starts to fail. Now if you want to explore the idea that a single test can run under multiple configurations (e.g. on a Module level and on an App level) like we do in the book, you would need some helpers to get around the new Security constraints. But what if the Security Module provided a Test Extension? In short, your own Modules provide Test Services / Management to the other modules.

Right, in many cases we found the warts inherent with Java EE or using Maven to manage the builds, and we tried our best to outline those and show some possible workarounds.

You're using all the latest and greatest. Including a REST/HATEOS driven backend for an AngularJS frontend. Do you believe that server side UI generation is dead?

No, server-side generation of the UI certainly has a place, as does client-side.  When you deal with dynamic elements only via JavaScript, this tends to give way to the common “loading” syndrome when the page is first rendered and then a series of async calls are made to pull in data.  On the other end of the spectrum, server-side generation can lead to a UI-only approach where services don’t need to be exposed in a RESTful fashion, and may in some cases be more resource-intensive than is necessary.  As with anything, we recommend that developers be aware of the strengths and limitations of each approach and choose solutions that best fit your requirements; sometimes a hybrid approach might be best.

In our case for GeekSeek, we’d simply felt that it was worth showing how to use the services of Java EE without necessarily using JSF for the view layer.  Having Angular tap into our RESTful interface to get at the backend data was a logical choice for us.

The book uses Java EE 6 as technology. And honestly I believe you did a great job. What do you think about Java EE generally and the improvements we got with EE 7 particularly. Wouldn't that have made your life easier?

It’s important that developers judge Java EE fairly; it’s aim is to standardize where appropriate and bring together a wide swath of disparate technologies.  It intentionally leaves choice to vendors in a number of areas, and by nature of being a standard cannot necessarily evolve as quickly as some may like, as that would cause too much instability inbetween major releases.  So it provides a very nice base upon which to build, and affords choice to the developer.

With that choice can come confusion, which is a large motivation for our book.  We look to illustrate a few ways of bringing the whole picture together.

Java EE 6 did have some limiting factors which we encountered and devised custom solutions to address.  For instance, JAX-RS 1.1 does not define interceptors, so we added a CDI-based interceptor chain to our REST layer.  And CDI 1.0 defines beans.xml metadata per archive with no global ordering or configuration, so we again added our own chain to address this.

WildFly was just certified as EE7-compliant during the book’s production process, and EAP will follow later, so we’ll look to provide updates to the application as time progresses; that’s why we’re releasing GeekSeek initially as an EE6 application.

You point your readers to JBDS and Forge for development. Honestly guys, which IDE are you using and why?

Aslak: Eclipse. For 15 years or so. I’m getting old, too many shortcuts built into my brain to change ;)

ALR: I use both standard Eclipse and the JBDS toolset, as well as IntelliJ IDEA Community.  It really depends upon what I’m doing; I love IDEA for most development and find it more resource-efficient, but I like m2e in Eclipse when I’m dealing with Maven dependency issues, and JBDS when doing anything with Forge or OpenShift because of the nice integration there.

The code runs on WildFly which isn't exactly a surprise. Do you test on other app-servers? Arquillian has a broad range of container adapters and I somehow expected to see some more here.

This again hits at the nature of Java EE; applications in compliance to the platform still need to run somewhere, and vendor differences start to show up when you put together a non-trivial application.  While porting between WildFly and EAP is generally a relatively-simple endeavor, there are still enough differences that running the exact same codebase on both targets requires some thought and intelligent implementation.  These gaps grow in orders of magnitude once you start to incorporate servers offered by other vendors, so for the sake of simplicity in delivering one source tree without forks to customize for individual application servers, we chose the community WildFly and free-for-development EAP (and its OpenShift cartridge) as runtimes.  We absolutely encourage our readers to port to their application server of choice and share their patches or experiences with us!

The book and source are licensed under Creative Commons. So, basically free to everybody and accessible on https://github.com/arquillian/continuous-enterprise-development. Why do you still do a printed version? What is the benefit of buying one? 

It’s really simple; we wanted the book to get into the hands of as many developers who might benefit from its lessons.  O’Reilly has a global reach and streamlined process to deliver to large online retailers and traditional brick-and-mortar stores, and they were open to our desire to deliver the text under an open-source license.  They additionally provide editorial and graphics work to really help deliver a more polished product than we’d have done on our own, so we decided to partner with them in the name of getting a higher-quality work out to as many people as possible.

I've always wondered how much work it actually is. Did you spend all your evenings on it? 

Aslak: I would say, roughly 2 months full time. The problem is when it’s not heads down full time, you lose so much built up contextual information along the way so it gets harder and harder the longer it goes between each write session.

ALR: Exactly; the work itself isn’t terrible in quantity, but when you couple it with a day job and have to deal with constant context-switching, it’s easy to let the book occupy more mental space than the actual time it takes to deliver would indicate.  It’s also not the kind of thing that you can do mindlessly; like software, writing requires a decent design phase and constant iterations to align your objectives with the code, and explain in a fashion that’s hopefully concise and complete.  It’s an exercise to our readers to judge how well we executed there. :)

WildFly 8 vs. GlassFish 4 – Which Application Server to Choose.

It's been a while since my last blog. I've obviously been busy with different things including my main job. After some more questions regarding the right choice for application servers cross my way it is the right time to pick this topic up again and share my thoughts.

One of the most read post on this blog is the post about which Java EE 6 application server to choose. I've been looking at a bunch of criteria and knocked down the different certified servers according to a very basic but common pattern. Given the main guideline that each server should be available as OSS and commercially supported variant the post concludes with recommending both GlassFish 3 and JBoss AS7 as valid choices. After the GlassFish roadmap updates from last November the situation seems to have changed and many people tend to accept that AS7/WildFly now remain the only alternative. Today I'd like to shift the focus on this a bit and try to put the discussion back into a more strategical context and elaborate further on the impact on the GlassFish vs. WildFly decision as of today.

Basic Strategy Principle for Java EE Applications
Beginning with having made the decision to develop a new application based on Java EE you already assumed a couple of things. Java EE is called an industry standard for a reason. It means it is widely adopted and still not officially captured by one of the official standards or standardization organisations like DIN/ISO or IEEE. The JCP provides rules and regulations for it and governs it along a broad contribution from different individuals and organizations. Calling it an open industry standard is common and valid for me. You may weight the difference between both on your own. In principle the Java EE certification list provides you with a range of different products which at least comply to the so called Java EE TCK. The TCK is heavily discussed and it is safe to assume that it does not cover every single line of all contained specifications completely. But every certified Java EE server should basically be ready to execute a Java EE application. The write once - run everywhere principle can be achieved (at least to a certain extend).
Bottom line of your decision is: Avoid (vendor) specific features and build your new application on an open industry standard which provides flexibility and choice between different products and vendors.
Beside this you gain additional value by having the flexibility to choose from a broad range of companies and developers offering skills and services in Java EE technologies.

WildFly 8 and GlassFish 4 are equal from a Java EE 7 Perspective
With the announcement of WildFly 8 CR1 it passes the Java EE 7 TCK. Even if the official paperwork obviously haven't been completely processed it looks like the 8 final will officially be certified. At least with regards to the Java EE 7 technologies both servers offer the same. There is and always has been different additional features surrounding the core technology stack but I haven't done a complete feature comparison of them and I honestly have no intend of doing it.
If you plan on doing a greenfield development come up with your own decision making process and weight those additional metrics in. You're already and Oracle or Red Hat customer? Or using additional infrastructural components which work best with the one or the other? In my experience you also need to weight in a couple of others (from my own experience we are talking about >=30) and rank them accordingly.

Migrate from GlassFish 2.x, 3.x to 4.0?
The most commonly asked question these days. What should I do with the applications which are already running on GlassFish 2.x or 3.x? It probably is the hardest one. I would need to know a bit more from you to answer it.

Oracle/GlassFish Customer/Shop and not changing anything?
Are you already using the Oracle GlassFish Server (commercially supported version) or are you using the Open Source version? Do you plan on extending the application or use newly introduced Java EE 7 features? If you are hooked up with Oracle or the commercial version already and you are NOT planning on making any changes you basically don't have to worry about migrating at all. Existing Oracle GlassFish Server 2.1.x and 3.1.x commercial customers will continue to be supported according to the Oracle Lifetime Support Policy (PDF). I basically don't recommend to migrate at all if you're in that kind of setting. The extended support for both servers ends in January 2017 (GFv2) respectively March 2019 (GFv3).

Oracle/GlassFish Customer/Shop and willing to use new Java EE 7 features early?
So you are an Oracle Customer and you are keen to use latest technology early? Or you need to heavily modify your applications?
You basically have three options: Stick with the GlassFish 4 OSS Version (without support contract) or move to the WebLogic 12c (12.1.4) which will most likely have full EE 7 support or do this step by step by first moving to GF 4 and then to WebLogic 12.1.4 later.
Directly switching to GlassFish and planning to go on with WebLogic in production later carries the risk of using different application servers in development and production. You need to value this in and handle it accordingly.
To completely reduce the risk I would recommend to wait for at least the WebLogic 12.1.3 which is expected to have a first set of new Java EE 7 specifications and will hopefully available sometime during the first half of CY2014.
If you don't run a mission critical application and you don't need a support contract I recommend to migrate to GlassFish 4.0 in order to facilitate the already available infrastructure and skills and contracts. To me there is no point in hastily switching vendors. Be prepared for ending support contracts and plan on evaluating your decisions about the right Open Source Application Server then.

Not really and Oracle Customer/Shop, not changing anything no interest in new EE 7 features?
Don't migrate at all until your requirements change. You might start evaluating your next Java EE 7 server product soon. But as of today there aren't many certified alternatives available.

Not really and Oracle Customer/Shop, changing requirements, will to use new EE 7 features?
Might be time to revisit your IT landscape this year. It seems as if you've decided to go with GlassFish at some point. You might have to revisit your former decision and evaluate what to do. To make a well grounded decision about your next Java EE server you are too early. The certification matrix for EE 7 servers is mostly empty. Wait for more alternatives to come up. I expect this to take most of CY2014.
If you have the need for new EE 7 features as of today and you need to be able to buy commercial support in the future but don't need it right here and now the only alternative you have is WildFly 8.

What does the future hold for GlassFish 4?
I wish I could tell you. I guess I made my points in the earlier posting. Oracle needs GlassFish to stick around as Java EE Reference Implementation and given the number of commonly used components in both WebLogic and GlassFish it will always be there. And it is safe to assume that the Java EE specifications will always be the latest and greatest in GlassFish. But the Java EE ecosystem lead to a bunch of vendor specific extensions and features which are not really covered by any specification. Those are commodity  to all of us (mostly clustering, admin Features, embedded server) and we don't want to miss them in many cases. Further on the patch frequency and grade of community participation will be crucial factors for the successful spread of GlassFish among projects and developers.

I’m speaking at OUGN Spring Conference 3rd-5th of April 2014, Oslo-Kiel

I'm pretty proud to announce, that I will be speaking at the annual OUGN spring seminar again. After my first time last year I was once again invited to speak by the Norwegian Oracle User Group (OUGN).

Last year's trip was sheer pleasure and I am very much looking forward to exciting talks and the unique conference experience that cruise ship provides. You can look at my photo sets on Google+ (Day 1, Day 2, Day 3 and Day 4) or at the complete trip report from last year to get a good impression about it.
This year, I'll give two presentations in both Java and the Middleware space this year.


Friday April 4, 2014 09:30 - 10:15 Congress 1+2 (Color Magic)
WebLogic 101 (P166)
This is a basic introduction into Java EE 6 and WebLogic 12c for everybody interested in the basics. Giving a brief overview about the needed skills and providing a guide to everything you need to know for getting started. No matter if you're a DBA or developer.

Thursday April 3, 2014 16:00 - 16:45 Congress 3 (Color Magic)
Developer Security Awareness (P163)
All the common attacks we've known about for a very long time are still out there, and people still regularly make mistakes regarding them. This is an engaging session about Java EE technology, people, and processes and how they best work together to build a suitable secure system. Derived from practice for use with everyday development, such a system can make the Java EE space a little more secure.

Additionally there will be plenty of time to talk and exchange experiences. Thanks for the invitation! I am very much looking forward seeing you there! Don't forget to have a look at the complete schedule and register if you haven't done so!

Another year is nearly over…

... and it is time to sit back and relax a bit. It has been exhausting for me on many levels and I tried not to leave any opportunity slip through. It is time to say thanks. I'm thankful for the many people seeing me sessions on conferences around the world. Thankful for the readers on this blog, for the feedback I receive on Twitter or even in person. Thankful for a steadily growing and strong Java community and even thankful for Oracle taking the steward job serious and not having burnt too many bridges this year.

There are plenty of things upcoming next year. All starts with the IOUC meeting in January, a great Jfokus conference in Stockholm in February, the JavaLand conference in March followed by the OUGN Vårseminar and the newly created DevNation conference in April. There are plenty of opportunities to meet and talk. I'm looking forward to this new year. And some silent days.
Wishing you a prosperous and happy new year


“We will open the book.
Its pages are blank.
We are going to put words on them ourselves.
The book is called Opportunity
and its first chapter is New Year's Day.”
― Edith Lovejoy Pierce

See me at DevNation, 13 – 17 April 2014, San Francisco, CA

I'm pretty proud to announce that I'll be speaking at the new open source, polyglot conference for application developers and maintainers DevNation 2014. It will be co-located with Red Hat Summit and will offer sessions, labs, and panels geared for those who build with open source.


As of today the official call for papers starts. Now it's on you to join the early announced speakers among myself, Mike Milinkovich (Eclipse), Chris Aniszczyk (Twitter), Arun Gupta (Red Hat).


While there will not be formal tracks you can send in proposals among the following topics that will likely fit into overall vibe including:

  • Enterprise Application Development (e.g. concurrent, multi-user applications with data stores, security, transactions, etc)
  • Front-end Development (e.g. display technologies, client-side scripting and layout, templating engines)
  • Mobile Development (e.g. Android, iOS, Cordova, HTML5 for mobile)
  • Big Data (e.g. RDBMS and NoSQL, persistent storage and associated computational problems with large data stores)
  • Application Integration (Service-Oriented Architecture)
  • DevOps and Continuous Delivery (e.g. build and deployment environments, administration and management)
  • Performance and Tuning (e.g. Analysis and techniques to get the best out of your applications)
  • Platform Development (ie. C++ and *nix applications)
  • Cool Stuff (Any helpful bits you'd love to share with your peers)

You can hook up with this awesome new conference by joining the twitter discussion @DevNationConf or tweet with the official #DevNation14 tag and don't forget to check back with the conference website frequently for new announcements.

Open registration begins in January 2014. Come to hack, come to learn. Join the Nation.

Project Avatar – What’s in it for Java EE 8?

With Java EE 7 out the door since a while it is already time to start planning for the next revision of the platform which will most likely be called Java EE 8. Oracle set up a community survey with which they would like to get input from the community on the relative importance of some of the features they intend to add. First of all this should encourage the interested reader to participate and take the survey. One particular point in it is all about support for HTML 5 based, dynamic applications. While WebSocket and JSON Processing already made it into Java EE 7 there is another feature particularly in GlassFish and WebLogic (via Jersey) at the moment which has some potential to be standardized. The Server Sent Events (SSE). It already is part of the HTML5 spec and would be a very good candidate for standardization. But Oracle is thinking even further and is asking if there would be enough support and interest to actually standardize the use of JavaScript on  Java EE servers. When this kind of question started to appear at JavaOne 2012 it was basically referred to as Node.jar on Nashorn. Since this September we know the real name: Project Avatar.

Avatar At A Glance
Project Avatar provides a JavaScript services layer zeroed in on supporting REST, WebSockets and Server-Sent Events, and a rich client side framework that assumes very minor JavaScript knowledge. The services side is focused on building data services using JavaScript, while the optional client side is entirely focused on supporting HTML5 and TSA (Thin Server Architecture).


Project Avatar (Source: avatar.java.net)

Thin Server Architecture
With the introduction of HTML5, CSS3 and fast JavaScript engines, modern browsers have become a powerful platform. In the advent of the so called single-page application (SPA), also known as single-page interface (SPI) the design of modern user interfaces shifted away from server side generation to web applications or web sites that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application. An SPA moves logic from the server to the client. This results in the role of the web server evolving into a pure data API or web service. This architectural approach has been coined "Thin Server Architecture" to indicate that complexity moved from the server to the client while reducing overall system complexity.

What is really in Avatar?
But Avatar is far more than just a TSA approach. It basically consists of three parts. The foundation is build by the upcoming Java 8 and its included JavaScript implementation called Nashorn. On top of it is the Avatar Runtime including an additional compiler layer and a Servlet API based server. Those abstractions  enable it to be hosted on various runtimes. Avatar applications are comprised of either client side ‘views’, server side ‘services’ or both. Importantly, there is no inherent coupling between them which enables views to communicate with existing services and for services to be consumed by any type of client. An application ‘archive’ is deployed on the server and is compiled to generate JavaScript tailored to the application. Generated JavaScript for views handles data-binding with the DOM/UI as well as data-management to remote services and local storage. The Avatar archives are somewhat similar to Java EE web-archives. They consist of a WEB-INF folder, an avatar.properties file in the root and either a views directory and/or a service directory. Both file-system directories or .zip (.war) files are supported by Avatar.

All that is left on the Server - Services
A service extends either a REST, WebSocket or Push (SSE) abstraction and it's life-cycle is completely handled by the framework. Service implementations can leverage built-in Node modules as well as most third-party modules. Thanks to Nashorn's support for direct invocation of Java code you can also use most Java libraries directly.

The Client Side - Views
A view is the HTML required by the browser. It also contains custom 'data-' HTML extensions and simple JavaScript models. Those views get translated by a (server-side) compiler before sending the complete SPA HTML file including the custom generated JavaScript to the browser.

Putting it all together. A Simple Example.
Oracle provides a decent set of examples and documentation for Avatar which basically is enough to get you started. First thing to try it out yourself is a JDK 8 Early Access Build for your OS. At the time of writing I tried it with the latest Developer Preview b118. After installing you need to get the latest GlassFish Open Source Edition 4.0 server and unzip it into a suitable location. Make sure it runs with the installed JDK 8 by either putting <jdk8>/bin to your PATH environment variable or adding the following entry to the <gf4>/glassfish/config asenv.bat/conf

set AS_JAVA=<jdk8>

Now go ahead to download latest avatar-1.0-ea.zip and expand it to the <gf4>/glassfish/ directory. After that you need to set a AVATAR_HOME environment variable and point it to the <gf4> install directory. And make sure to add %AVATAR_HOME%glassfishbin to your PATH environment variable.
If all of that is done you can switch to your workspace folder and issue the following command to have Avatar creating a simple example app for you:

avatar new --example=hello

It creates a basic "hello" application which only consists of a view. It is a good place to start exploring and you can directly start your Glassfish instance afterwards and deploy the application as you would with every typical Java EE application:


asadmin start-domain


asadmin deploy hello


The "hello-example" app.
Pointing your browser to http://localhost:8080/hello will display the application. You can start editing the view located at <workspace>/hello/view/src/hello.html directly. While the server is running Avatar takes care of re-compiling it directly for the next request. This ensures a rapid development. This behavior is controlled by the "debug=true" property in the avatar.properties file and can be altered for productive systems. Further on, setting it to false causes all .js and .css files to be minimized before delivery.
At least if you first download and add the required YUI Compressor (jar download) to Avatar first. Due to license restrictions it hasn't been bundled. Simply put it into <gf4>/glassfish/modules/avatar-ext/lib. You might need to create that directory first.

Beside this very simple example without any service at all there are more complex ones available with the distribution at %AVATAR_HOME%/Project-Avatar-examples/. For convenience reasons there is a complete examples.ear available which can be directly deployed and tested. To access the samples simply prefix the example name with "demo-". So the "rest" example can be accessed via http://localhost:8080/demo-rest/.
TodoMVC - Example App with Avatar
You have to look out for different features to be showcased in the different examples. If you want to know how Avatar handles persistence you can exactly look into the rest example which uses a FileDataProvider to save the items. Another interesting example is the TodoMVC based app (http://localhost:8080/demo-todo/). It showcases a more complex view which also has been styled.

What is next?
As of today nobody knows what is going to happen with Avatar. The community feedback hasn't been tremendously loud or excited in general. I guess the reason for it is that nobody really knows what to do with it. The biggest drawback as of today is, that it only runs with GlassFish which will further limit adoption and community interest. Given the fact, that SSE isn't part of the Java EE specification it might make it even more difficult to port it to other app-server. Even if the license (GPL2 with Classpath Exception) should allow it. Back to the initial survey and the thought about specifying a server side JavaScript integration with Java EE, you know at least have a brief idea about what Oracle is talking if they are talking about Avatar. Go ahead and take that survey and tell them what you are thinking about having that kind of stuff in Java EE.

Meta: this post is part of the Java Advent Calendar and is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on!

Project Avatar – What’s in it for Java EE 8?

With Java EE 7 out the door since a while it is already time to start planning for the next revision of the platform which will most likely be called Java EE 8. Oracle set up a community survey with which they would like to get input from the community on the relative importance of some of the features they intend to add. First of all this should encourage the interested reader to participate and take the survey. One particular point in it is all about support for HTML 5 based, dynamic applications. While WebSocket and JSON Processing already made it into Java EE 7 there is another feature particularly in GlassFish and WebLogic (via Jersey) at the moment which has some potential to be standardized. The Server Sent Events (SSE). It already is part of the HTML5 spec and would be a very good candidate for standardization. But Oracle is thinking even further and is asking if there would be enough support and interest to actually standardize the use of JavaScript on  Java EE servers. When this kind of question started to appear at JavaOne 2012 it was basically referred to as Node.jar on Nashorn. Since this September we know the real name: Project Avatar.

Avatar At A Glance
Project Avatar provides a JavaScript services layer zeroed in on supporting REST, WebSockets and Server-Sent Events, and a rich client side framework that assumes very minor JavaScript knowledge. The services side is focused on building data services using JavaScript, while the optional client side is entirely focused on supporting HTML5 and TSA (Thin Server Architecture).


Project Avatar (Source: avatar.java.net)

Thin Server Architecture
With the introduction of HTML5, CSS3 and fast JavaScript engines, modern browsers have become a powerful platform. In the advent of the so called single-page application (SPA), also known as single-page interface (SPI) the design of modern user interfaces shifted away from server side generation to web applications or web sites that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application. An SPA moves logic from the server to the client. This results in the role of the web server evolving into a pure data API or web service. This architectural approach has been coined "Thin Server Architecture" to indicate that complexity moved from the server to the client while reducing overall system complexity.

What is really in Avatar?
But Avatar is far more than just a TSA approach. It basically consists of three parts. The foundation is build by the upcoming Java 8 and its included JavaScript implementation called Nashorn. On top of it is the Avatar Runtime including an additional compiler layer and a Servlet API based server. Those abstractions  enable it to be hosted on various runtimes. Avatar applications are comprised of either client side ‘views’, server side ‘services’ or both. Importantly, there is no inherent coupling between them which enables views to communicate with existing services and for services to be consumed by any type of client. An application ‘archive’ is deployed on the server and is compiled to generate JavaScript tailored to the application. Generated JavaScript for views handles data-binding with the DOM/UI as well as data-management to remote services and local storage. The Avatar archives are somewhat similar to Java EE web-archives. They consist of a WEB-INF folder, an avatar.properties file in the root and either a views directory and/or a service directory. Both file-system directories or .zip (.war) files are supported by Avatar.

All that is left on the Server - Services
A service extends either a REST, WebSocket or Push (SSE) abstraction and it's life-cycle is completely handled by the framework. Service implementations can leverage built-in Node modules as well as most third-party modules. Thanks to Nashorn's support for direct invocation of Java code you can also use most Java libraries directly.

The Client Side - Views
A view is the HTML required by the browser. It also contains custom 'data-' HTML extensions and simple JavaScript models. Those views get translated by a (server-side) compiler before sending the complete SPA HTML file including the custom generated JavaScript to the browser.

Putting it all together. A Simple Example.
Oracle provides a decent set of examples and documentation for Avatar which basically is enough to get you started. First thing to try it out yourself is a JDK 8 Early Access Build for your OS. At the time of writing I tried it with the latest Developer Preview b118. After installing you need to get the latest GlassFish Open Source Edition 4.0 server and unzip it into a suitable location. Make sure it runs with the installed JDK 8 by either putting <jdk8>/bin to your PATH environment variable or adding the following entry to the <gf4>/glassfish/config asenv.bat/conf

set AS_JAVA=<jdk8>

Now go ahead to download latest avatar-1.0-ea.zip and expand it to the <gf4>/glassfish/ directory. After that you need to set a AVATAR_HOME environment variable and point it to the <gf4> install directory. And make sure to add %AVATAR_HOME%glassfishbin to your PATH environment variable.
If all of that is done you can switch to your workspace folder and issue the following command to have Avatar creating a simple example app for you:

avatar new --example=hello

It creates a basic "hello" application which only consists of a view. It is a good place to start exploring and you can directly start your Glassfish instance afterwards and deploy the application as you would with every typical Java EE application:


asadmin start-domain


asadmin deploy hello


The "hello-example" app.
Pointing your browser to http://localhost:8080/hello will display the application. You can start editing the view located at <workspace>/hello/view/src/hello.html directly. While the server is running Avatar takes care of re-compiling it directly for the next request. This ensures a rapid development. This behavior is controlled by the "debug=true" property in the avatar.properties file and can be altered for productive systems. Further on, setting it to false causes all .js and .css files to be minimized before delivery.
At least if you first download and add the required YUI Compressor (jar download) to Avatar first. Due to license restrictions it hasn't been bundled. Simply put it into <gf4>/glassfish/modules/avatar-ext/lib. You might need to create that directory first.

Beside this very simple example without any service at all there are more complex ones available with the distribution at %AVATAR_HOME%/Project-Avatar-examples/. For convenience reasons there is a complete examples.ear available which can be directly deployed and tested. To access the samples simply prefix the example name with "demo-". So the "rest" example can be accessed via http://localhost:8080/demo-rest/.
TodoMVC - Example App with Avatar
You have to look out for different features to be showcased in the different examples. If you want to know how Avatar handles persistence you can exactly look into the rest example which uses a FileDataProvider to save the items. Another interesting example is the TodoMVC based app (http://localhost:8080/demo-todo/). It showcases a more complex view which also has been styled.

What is next?
As of today nobody knows what is going to happen with Avatar. The community feedback hasn't been tremendously loud or excited in general. I guess the reason for it is that nobody really knows what to do with it. The biggest drawback as of today is, that it only runs with GlassFish which will further limit adoption and community interest. Given the fact, that SSE isn't part of the Java EE specification it might make it even more difficult to port it to other app-server. Even if the license (GPL2 with Classpath Exception) should allow it. Back to the initial survey and the thought about specifying a server side JavaScript integration with Java EE, you know at least have a brief idea about what Oracle is talking if they are talking about Avatar. Go ahead and take that survey and tell them what you are thinking about having that kind of stuff in Java EE.

Meta: this post is part of the Java Advent Calendar and is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on!

My vJUG Session: Don’t Be That Guy! Developer Security Awareness

I've been invited to talk at the vJUG which is the newest JUG around. A virtual JUG reaching out to interested Java Developers over all time zones and locations. The  aim is to get the greatest minds and speakers of the Java industry giving talks and presentations for this community, in the form of webinars and JUG session streaming from JUG f2f meetups.

"Don't be that guy! Developer Security Awareness" by Markus Eisele
Was a session already scheduled for JavaOne this year. Due to scheduling conflicts I actually had to cancel it and I was pretty excited to finally be able to deliver it to the many who signed up for the session in SF. With 174 registered attendees I count this as a success.

The session was given via Google Hangout (Thanks Google!) and recorded to Youtube for you to re-watch.

The slides are on speakerdeck.com:
Thanks everybody for attending! It was a pleasure!

My vJUG Session: Don’t Be That Guy! Developer Security Awareness

I've been invited to talk at the vJUG which is the newest JUG around. A virtual JUG reaching out to interested Java Developers over all time zones and locations. The  aim is to get the greatest minds and speakers of the Java industry giving talks and presentations for this community, in the form of webinars and JUG session streaming from JUG f2f meetups.

"Don't be that guy! Developer Security Awareness" by Markus Eisele
Was a session already scheduled for JavaOne this year. Due to scheduling conflicts I actually had to cancel it and I was pretty excited to finally be able to deliver it to the many who signed up for the session in SF. With 174 registered attendees I count this as a success.

The session was given via Google Hangout (Thanks Google!) and recorded to Youtube for you to re-watch.

The slides are on speakerdeck.com:
Thanks everybody for attending! It was a pleasure!

R.I.P. GlassFish – Thanks for all the fish.

We've all heard it coming probably. Yesterday the official roadmap update for JavaEE and GlassFish was updated and published. And beginning with the title the whole post was basically about one thing: GlassFish Server as we know it today is deprecated from a full blown product to a toy product.

The Long Road from Sun to Oracle
GlassFish was something to worry about right from the start. After the merger it took some time to silence the voices which insisted on "Oracle killing GlassFish". Oracle did a decent job in nurturing the community and keeping their stuff together. I've written a couple of blogs myself helping to get the word out. The 100-day releases 2.1.2 and 3.0.1 have somehow become the milestone to prove the will to improve. And we all have been fine with it after a while. Even back in January 2013 I compiled a list of open source application servers and which one to pick. The final criteria was vendor support. That kicked WAS CE out of the game. As of yesterday it would also removed GlassFish. The two remaining alternatives burned down to one: Which is JBoss AS7 / WildFly.

Customers Need Support for their Servers
But come on, what is the issue here? Who wants support anyway? And Oracle obviously did not make enough money out of the commercial licenses otherwise they wouldn't have killed the offering at all. It might not be a very obvious reason but I can offer some kind of explanation. First of all if a vendor is not only developing an open source alternative but also has a commercial offering this leads to different things that will be taken care of implicitly:
- Changes/Bugs discovered by customers go into the oss release
- Changes need to have a decent quality. Developers knowing about the need to support their solutions will be (at least a bit) more careful implementing stuff.
- Developers knowing that their stuff is run under decent load think differently implementing it. The complete list of non-functional criteria changes with that move.
- Customers demand more frequent releases and security patches which also end up in the oss version.
- Customers have different requirements than people using free and open source servers. One prominent example is clustering. Which is rarely used among oss projects.

Another factor is driven by experience. I would never try to develop project on a completely different setting than the production setting is at. Even that both WLS and GF understand at least a bit of each others deployment descriptors there is a high risk buried in here that such a setting is the road to trouble.

The bottom line of my argumentation basically is, that the need for providing a commercial distribution improves the overall quality and reliability by changing some relevant non functional requirements for the product. If those aren't there and nobody is consequently taking care of them ... they will not be in there.

Why will Java EE suffer from a dead GlassFish?
The quality of the Java EE TCK has been questioned a lot. And in the past many people used GF as a showcase for not working code. On top of that some production scenarios and errors lead to different implementations and last but not least specifications. All the practical field knowledge has been in the heads of the team. I don't know how Oracle is running WLS development internally but I expect it do be different from what the team did for GF, probably a bit heavier. Extracting specification edge-cases and removing product specific parts from WLS based customer cases will for sure be trickier and not happen very frequently. So I expect the spec to be a little less Oracle driven and a little less mature generally. Not the worst part in the story. But given the fact that some very bright minds are working in that area I expect that their passion and knowledge will be missed a lot. And there is nobody there to catch them falling.

Which Parts of GlassFish will die?
So GlassFish will stay the reference implementation for upcoming Java EE standards. Oracle needs it to be around just for that one reason. With the emerging JCP which is becoming more and more open it isn't a big surprise that they are not simply going to define WLS as the RI. But that will be the cut between things that will die and things that will be around. I DON'T have any insights here and I'm just speculating and I could make an educated guess about the first comment on this blog but .. bottom line for me is, that everything that isn't covered by the Java EE spec is going to age very fast. This could include clustering and for sure some of the admin features and security also is a good candidate (PAM realm and others). And frankly I can't confirm any of them. It is pure speculation!

Is there a good part in that at all?
Well, yes: The move leaves a field wide open for strengthened competition. And this is not only WildFly but for sure also TomEE with tomitribe. Congratulations to them. Further on many customers will save a lot of license fees. GF and WLS are differently licensed and using WLS standard gives customers more options on picking the right license. And at least the WLS team will be strengthened with those people don't having to switch heads anymore working frequently on different products.

Can Oracle do something to make the killing worth it?
As of today it is a senseless death. Users can simply sit back and wait for the next minor release which probably will happen once a year. If you've been complaining about infrequent releases until today .. prepare for even less in the future. There are indeed a couple of things Oracle could do to make this a strategic move for everybody and not only themselves:
1) Develop and support a clear upgrade path. Find a way to at least support a development setting based on a very lightweight server and only deploy to a full blown WLS in production. With the given features and differences between the two this is hardly a working story as of today.
2) Make an attractive licensing offering for GF users. Not only to the customers as of today but for all. Or even better: Come up with a bunch of licensing terms in the OTN license which allows NPOs to use WLS free of charge.
3) Consequently open-source GF (under a decent license) and make community contributions attractive. The used infrastructure and OCA makes this impossible as of today. Move the server code (including modules) to GitHub and appoint a change manager who reviews and pulls in proposed fixes and changes. Let the community decide on releases.

The Echoes Are Gone In The Hall
Basically the news isn't a big surprise. We all understand the move. Having two servers instead of one is a double burden. With the BEA merger Oracle killed their own application server. Now it was GlassFish's turn. Oracle already tried to reduce the needed efforts to maintain it by merging the teams and also discussed different options along merging WLS to HK2 or extending the use of the same components for both servers. Some things happened and pushed the time for yesterdays announcement out by a couple of months but finally did not prevent it. So. R.I.P. GlassFish. It was nice. Thanks for all the fish.



R.I.P. GlassFish – Thanks for all the fish.

We've all heard it coming probably. Yesterday the official roadmap update for JavaEE and GlassFish was updated and published. And beginning with the title the whole post was basically about one thing: GlassFish Server as we know it today is deprecated from a full blown product to a toy product.

The Long Road from Sun to Oracle
GlassFish was something to worry about right from the start. After the merger it took some time to silence the voices which insisted on "Oracle killing GlassFish". Oracle did a decent job in nurturing the community and keeping their stuff together. I've written a couple of blogs myself helping to get the word out. The 100-day releases 2.1.2 and 3.0.1 have somehow become the milestone to prove the will to improve. And we all have been fine with it after a while. Even back in January 2013 I compiled a list of open source application servers and which one to pick. The final criteria was vendor support. That kicked WAS CE out of the game. As of yesterday it would also removed GlassFish. The two remaining alternatives burned down to one: Which is JBoss AS7 / WildFly.

Customers Need Support for their Servers
But come on, what is the issue here? Who wants support anyway? And Oracle obviously did not make enough money out of the commercial licenses otherwise they wouldn't have killed the offering at all. It might not be a very obvious reason but I can offer some kind of explanation. First of all if a vendor is not only developing an open source alternative but also has a commercial offering this leads to different things that will be taken care of implicitly:
- Changes/Bugs discovered by customers go into the oss release
- Changes need to have a decent quality. Developers knowing about the need to support their solutions will be (at least a bit) more careful implementing stuff.
- Developers knowing that their stuff is run under decent load think differently implementing it. The complete list of non-functional criteria changes with that move.
- Customers demand more frequent releases and security patches which also end up in the oss version.
- Customers have different requirements than people using free and open source servers. One prominent example is clustering. Which is rarely used among oss projects.

Another factor is driven by experience. I would never try to develop project on a completely different setting than the production setting is at. Even that both WLS and GF understand at least a bit of each others deployment descriptors there is a high risk buried in here that such a setting is the road to trouble.

The bottom line of my argumentation basically is, that the need for providing a commercial distribution improves the overall quality and reliability by changing some relevant non functional requirements for the product. If those aren't there and nobody is consequently taking care of them ... they will not be in there.

Why will Java EE suffer from a dead GlassFish?
The quality of the Java EE TCK has been questioned a lot. And in the past many people used GF as a showcase for not working code. On top of that some production scenarios and errors lead to different implementations and last but not least specifications. All the practical field knowledge has been in the heads of the team. I don't know how Oracle is running WLS development internally but I expect it do be different from what the team did for GF, probably a bit heavier. Extracting specification edge-cases and removing product specific parts from WLS based customer cases will for sure be trickier and not happen very frequently. So I expect the spec to be a little less Oracle driven and a little less mature generally. Not the worst part in the story. But given the fact that some very bright minds are working in that area I expect that their passion and knowledge will be missed a lot. And there is nobody there to catch them falling.

Which Parts of GlassFish will die?
So GlassFish will stay the reference implementation for upcoming Java EE standards. Oracle needs it to be around just for that one reason. With the emerging JCP which is becoming more and more open it isn't a big surprise that they are not simply going to define WLS as the RI. But that will be the cut between things that will die and things that will be around. I DON'T have any insights here and I'm just speculating and I could make an educated guess about the first comment on this blog but .. bottom line for me is, that everything that isn't covered by the Java EE spec is going to age very fast. This could include clustering and for sure some of the admin features and security also is a good candidate (PAM realm and others). And frankly I can't confirm any of them. It is pure speculation!

Is there a good part in that at all?
Well, yes: The move leaves a field wide open for strengthened competition. And this is not only WildFly but for sure also TomEE with tomitribe. Congratulations to them. Further on many customers will save a lot of license fees. GF and WLS are differently licensed and using WLS standard gives customers more options on picking the right license. And at least the WLS team will be strengthened with those people don't having to switch heads anymore working frequently on different products.

Can Oracle do something to make the killing worth it?
As of today it is a senseless death. Users can simply sit back and wait for the next minor release which probably will happen once a year. If you've been complaining about infrequent releases until today .. prepare for even less in the future. There are indeed a couple of things Oracle could do to make this a strategic move for everybody and not only themselves:
1) Develop and support a clear upgrade path. Find a way to at least support a development setting based on a very lightweight server and only deploy to a full blown WLS in production. With the given features and differences between the two this is hardly a working story as of today.
2) Make an attractive licensing offering for GF users. Not only to the customers as of today but for all. Or even better: Come up with a bunch of licensing terms in the OTN license which allows NPOs to use WLS free of charge.
3) Consequently open-source GF (under a decent license) and make community contributions attractive. The used infrastructure and OCA makes this impossible as of today. Move the server code (including modules) to GitHub and appoint a change manager who reviews and pulls in proposed fixes and changes. Let the community decide on releases.

The Echoes Are Gone In The Hall
Basically the news isn't a big surprise. We all understand the move. Having two servers instead of one is a double burden. With the BEA merger Oracle killed their own application server. Now it was GlassFish's turn. Oracle already tried to reduce the needed efforts to maintain it by merging the teams and also discussed different options along merging WLS to HK2 or extending the use of the same components for both servers. Some things happened and pushed the time for yesterdays announcement out by a couple of months but finally did not prevent it. So. R.I.P. GlassFish. It was nice. Thanks for all the fish.



JavaLand 2014 – CfP Statistics And Answers To Common Questions

You probably have heard about the new upcoming Java centered conference in Germany next year. JavaLand 2014 will open its gates for two days. So make sure you are around when this new conference will become the hub of the German Java developer scene. I'm proudly part of the conference organizers and as a program chair I get plenty of help from the awesome program committee which was recruited out of the German JUG umbrella called iJUG.

With every new conference or thing to happen people start asking questions. Until the final schedule isn't published and the first conference is run, most of it is unanswered. But I like to give you a solid first set of impressions about the conference. The following charts and arts are generated based on the more than 400(!) paper submissions we got during the official CfP! It is intended to give you a first impression but will probably not completely reflect the finished conference schedule which will be out shortly (expected: mid November).

The Topics - An Overview
First of all I tweeted a Wordle about the submitted topics.
Basically a broad mix around Java. It is quite interesting to see, that there is quite a bit of Spring in there and JavaFX absolutely was among the big topics. It was good to see, that JVM based languages also got some love because this conference is intended to host different topics around the JVM as a runtime and as such give exposure to all the different JVM languages also. Enterprise and Mobile together with different DevOps topics are spread among the place. If you look carefully you see some German in it. As of today we don't know the ratio between German and English talks. But given the fact that we got a good number of international proposals I expect it to play a role. We basically don't focus on either one. As long as there is good content in it.

Proposed Talks from 18 Different Countries
Overall we got proposals from mostly Europe and the States. In total 18 different countries. Which is amazing! A big "Thank you!" to all the submitters!

What role does Oracle play?
Next big question is what role does Oracle play in all that. The conference is organized by German Oracle User Group (DOAG) and many suspect any (probably unfair) Oracle involvement. The only thing I can reply to it is: There isn't anything wrong going on here. Oracle actually IS supporting this conference along the lines they did before with the annual DOAG Conference and Exhibition. Given the fact, that the DOAG Conference will be hosting less and less Java over the next years Oracle was given the chance to submit talks. Like anybody else could. Additionally they host program committee meetings in their locations. Which was incredibly kind of them. That is great support for the German Java Community!
The overall ratio Oracle vs. Non-Oracle talks in the CfP was 6:94 ... Yes, only 6 out of 100 talks were proposed by Oracle employees. This is not a typical Oracle conference ratio. If you compare the numbers I published from last year's JavaOne the Oracle Speakers take up to 30%.

What will the content look like?
A great question. We don't know yet. The last PC meeting will happen shortly but what I can tell you is how the overall distribution looks like according to the submitted proposals:

Comparable evenly distributed. Except that we got too less security submissions. But at least some good ones. I expected to see more JVM languages talks but the feedback we're taking here is that we did a bad job communicating the focus correctly. We'll try to correct this. We're beginners here. Please be patient ;)

What about the Rest?
There is plenty of stuff upcoming. We are hosting a complete scheduled conference and plan on different community centered activities around it. We also will have some other surprises in stock. Announcements are pending but will follow shortly. Best is to follow @iJUGeV or @myfear on Twitter to stay up to date.

Can I book? Where? How? How much?
Sure you can. The registration is open since a couple of days already. Going for a registration until the 01/31/2014 you get the non-iJUG member price for €250/day. If you're an iJUG Member you get it for €200/day! Which both is nothing!
Find all the details on the registration page. I'm looking forward meeting you there! If you have additional questions feel free to ask! I'll try to answer!

JavaLand 2014 – CfP Statistics And Answers To Common Questions

You probably have heard about the new upcoming Java centered conference in Germany next year. JavaLand 2014 will open its gates for two days. So make sure you are around when this new conference will become the hub of the German Java developer scene. I'm proudly part of the conference organizers and as a program chair I get plenty of help from the awesome program committee which was recruited out of the German JUG umbrella called iJUG.

With every new conference or thing to happen people start asking questions. Until the final schedule isn't published and the first conference is run, most of it is unanswered. But I like to give you a solid first set of impressions about the conference. The following charts and arts are generated based on the more than 400(!) paper submissions we got during the official CfP! It is intended to give you a first impression but will probably not completely reflect the finished conference schedule which will be out shortly (expected: mid November).

The Topics - An Overview
First of all I tweeted a Wordle about the submitted topics.
Basically a broad mix around Java. It is quite interesting to see, that there is quite a bit of Spring in there and JavaFX absolutely was among the big topics. It was good to see, that JVM based languages also got some love because this conference is intended to host different topics around the JVM as a runtime and as such give exposure to all the different JVM languages also. Enterprise and Mobile together with different DevOps topics are spread among the place. If you look carefully you see some German in it. As of today we don't know the ratio between German and English talks. But given the fact that we got a good number of international proposals I expect it to play a role. We basically don't focus on either one. As long as there is good content in it.

Proposed Talks from 18 Different Countries
Overall we got proposals from mostly Europe and the States. In total 18 different countries. Which is amazing! A big "Thank you!" to all the submitters!

What role does Oracle play?
Next big question is what role does Oracle play in all that. The conference is organized by German Oracle User Group (DOAG) and many suspect any (probably unfair) Oracle involvement. The only thing I can reply to it is: There isn't anything wrong going on here. Oracle actually IS supporting this conference along the lines they did before with the annual DOAG Conference and Exhibition. Given the fact, that the DOAG Conference will be hosting less and less Java over the next years Oracle was given the chance to submit talks. Like anybody else could. Additionally they host program committee meetings in their locations. Which was incredibly kind of them. That is great support for the German Java Community!
The overall ratio Oracle vs. Non-Oracle talks in the CfP was 6:94 ... Yes, only 6 out of 100 talks were proposed by Oracle employees. This is not a typical Oracle conference ratio. If you compare the numbers I published from last year's JavaOne the Oracle Speakers take up to 30%.

What will the content look like?
A great question. We don't know yet. The last PC meeting will happen shortly but what I can tell you is how the overall distribution looks like according to the submitted proposals:

Comparable evenly distributed. Except that we got too less security submissions. But at least some good ones. I expected to see more JVM languages talks but the feedback we're taking here is that we did a bad job communicating the focus correctly. We'll try to correct this. We're beginners here. Please be patient ;)

What about the Rest?
There is plenty of stuff upcoming. We are hosting a complete scheduled conference and plan on different community centered activities around it. We also will have some other surprises in stock. Announcements are pending but will follow shortly. Best is to follow @iJUGeV or @myfear on Twitter to stay up to date.

Can I book? Where? How? How much?
Sure you can. The registration is open since a couple of days already. Going for a registration until the 01/31/2014 you get the non-iJUG member price for €250/day. If you're an iJUG Member you get it for €200/day! Which both is nothing!
Find all the details on the registration page. I'm looking forward meeting you there! If you have additional questions feel free to ask! I'll try to answer!

New Article in German iX Magazine: CapeDwarf

Another article hit the road today. This time a comprehensive introduction to CapeDwarf which is Red Hat's Google App Engine implementation for AS 7. In German iX Magazine 11/2013.

Flexible 
CapeDwarf tries to bring Google's App Engine to JBoss AS7
Red Hat's CapeDwarf project tries to bring two well-established technologies together: Google App Engine and Red Hat's Java EE server AS 7. The aim of the project is to implement all the APIs that Google App Engine provides and make them available on the application server.

This is a German article and you can either grab the latest issue online or buy it at your favorite kiosk.

Find some other articles of mine by searching this blog for posts labeled "article" and you get some results.

New Article in German iX Magazine: CapeDwarf

Another article hit the road today. This time a comprehensive introduction to CapeDwarf which is Red Hat's Google App Engine implementation for AS 7. In German iX Magazine 11/2013.

Flexible 
CapeDwarf tries to bring Google's App Engine to JBoss AS7
Red Hat's CapeDwarf project tries to bring two well-established technologies together: Google App Engine and Red Hat's Java EE server AS 7. The aim of the project is to implement all the APIs that Google App Engine provides and make them available on the application server.

This is a German article and you can either grab the latest issue online or buy it at your favorite kiosk.

Find some other articles of mine by searching this blog for posts labeled "article" and you get some results.

Review: "TestNG Beginner’s Guide" by Varun Menon

Packt was so kind to send me another book to look at. I've always been curious about testing in general and I was looking for some good stuff to hand to co-workers or otherwise interested people to get started with TestNG.

Abstract
Unit/Functional testing has now become part of every development life cycle. Junit was once the main framework that was used by developers for the purpose of Unit testing when it came to Java. But Junit had certain limitations in terms of execution and features. This book explains about the features and usage of TestNg, a new framework that overcomes Junit’s limitations and provides a lot of extra features.
TestNg Beginner’s Guide is a practical, hands-on guide that aims to increase your knowledge of TestNg. This step-by-step guide will help you to learn and understand the different TestNg features, and you will learn about the advantages and how to use and configure each feature according to your needs.

Book: TestNG Beginner's Guide
Language: English
Paperback: 276 pages [ 9.2 x 7.5 x 0.6 inches]
Release Date: July 26, 2013
ISBN-10: 1782166009
ISBN-13: 978-1782166009

About the Author
Varun Menon is a QA consultant with several years of experience in developing automation frameworks on various technologies and languages such as Java, JavaScript, Ruby, and Groovy. He has worked on web and mobile applications for some of the leading clients in the field of supply chain management, online photo books, video analytics, and market research.

The Content
Chapter one gives a brief introduction about testing and test automation. How to get started with TestNG, where to get it from and how to integrate it into your favorite IDE. Eclipse is used throughout the book. Chapter two deals with the basic configuration and introduces test suites and the command prompt usage. It also adds a couple of tests for packages, classes and methods. Chapter three is all about annotations. Setup and destroy, disabling tests and how to use parameterization. Test groups are introduced in chapter four followed by adding dependencies in chapter five. Chapter six and seven deal with the factory annotation and parallelism in tests. Chapter eight gives an overview about build tool integration covering Ant and Maven. Logging and reporting about test runs is covered in chapter nine. Programmatic test creation is covered in chapter ten. A basic migration scenario is covered in chapter 11. The closing chapter deals with the differences between unit and functional testing and explains additional concepts like JMock, Mockito and how to use Selenium.

Writing and Style
Generally the instructions are clear and the screen-shots are helpful. The overall level of detail and mixed in complexity is appropriate. Overall an easy read and well structured. Great for beginners and even developers familiar with the topic could still use it as a reference.

Conclusion and recommendation
The book is aimed at introducing developers to TestNG. It uses numerous screenshots and code listings to introduce core features. and only requires basic Java and probably JUnit knowledge. The book is aimed at Java developers who are unfamiliar with TestNG. If you're completely new to testing and TestNG in particular it is worth a read. One trade off is the very basic style of the examples. Additionally it does not tell you about why to use that feature or when to use another.

Review: "TestNG Beginner’s Guide" by Varun Menon

Packt was so kind to send me another book to look at. I've always been curious about testing in general and I was looking for some good stuff to hand to co-workers or otherwise interested people to get started with TestNG.

Abstract
Unit/Functional testing has now become part of every development life cycle. Junit was once the main framework that was used by developers for the purpose of Unit testing when it came to Java. But Junit had certain limitations in terms of execution and features. This book explains about the features and usage of TestNg, a new framework that overcomes Junit’s limitations and provides a lot of extra features.
TestNg Beginner’s Guide is a practical, hands-on guide that aims to increase your knowledge of TestNg. This step-by-step guide will help you to learn and understand the different TestNg features, and you will learn about the advantages and how to use and configure each feature according to your needs.

Book: TestNG Beginner's Guide
Language: English
Paperback: 276 pages [ 9.2 x 7.5 x 0.6 inches]
Release Date: July 26, 2013
ISBN-10: 1782166009
ISBN-13: 978-1782166009

About the Author
Varun Menon is a QA consultant with several years of experience in developing automation frameworks on various technologies and languages such as Java, JavaScript, Ruby, and Groovy. He has worked on web and mobile applications for some of the leading clients in the field of supply chain management, online photo books, video analytics, and market research.

The Content
Chapter one gives a brief introduction about testing and test automation. How to get started with TestNG, where to get it from and how to integrate it into your favorite IDE. Eclipse is used throughout the book. Chapter two deals with the basic configuration and introduces test suites and the command prompt usage. It also adds a couple of tests for packages, classes and methods. Chapter three is all about annotations. Setup and destroy, disabling tests and how to use parameterization. Test groups are introduced in chapter four followed by adding dependencies in chapter five. Chapter six and seven deal with the factory annotation and parallelism in tests. Chapter eight gives an overview about build tool integration covering Ant and Maven. Logging and reporting about test runs is covered in chapter nine. Programmatic test creation is covered in chapter ten. A basic migration scenario is covered in chapter 11. The closing chapter deals with the differences between unit and functional testing and explains additional concepts like JMock, Mockito and how to use Selenium.

Writing and Style
Generally the instructions are clear and the screen-shots are helpful. The overall level of detail and mixed in complexity is appropriate. Overall an easy read and well structured. Great for beginners and even developers familiar with the topic could still use it as a reference.

Conclusion and recommendation
The book is aimed at introducing developers to TestNG. It uses numerous screenshots and code listings to introduce core features. and only requires basic Java and probably JUnit knowledge. The book is aimed at Java developers who are unfamiliar with TestNG. If you're completely new to testing and TestNG in particular it is worth a read. One trade off is the very basic style of the examples. Additionally it does not tell you about why to use that feature or when to use another.