The inaugural Voxxed Days Algiers was held on May 23 in Algiers, Algeria. Besides the Devoxx and Voxxed brand, the event can be credited by and large to the grassroots efforts of the Algeria JUG as well as the neighboring Morocco JUG. I have to thank Morocco JUG leader Badr El Houari for cordially inviting me to the event and Algeria JUG leader Abderrazak Bouadma for making the trip a unique unforgettable experience. The event was a humble but profound first step in the right direction for Algerian developers. The event definitely had a strong Java EE showing.
I participated in the opening keynote and delivered three sessions on Java EE 8, using NoSQL in Java EE applications and testing Java EE applications with Arquillian. More details on the sessions and Voxxed Days Algiers, including slide decks and code, posted on my personal blog.
This is the first in a series of interviews for you to meet some of the committee members for the JavaOne 2015 Java EE track. The committee plays the most important part in determining the content for JavaOne. These good folks really deserve recognition as most of them devote many hours of their time helping move JavaOne forward, often as volunteers. If JavaOne matters to you, these are folks you should know about.
This first interview is with Markus Eisele. If you are having trouble seeing the embedded video below it is available here.
Markus is now a Developer Advocate at Red Hat and focuses on JBoss Middleware. He has been a long time community advocate for Java EE. He is a popular blogger, author, prolific speaker, JCP expert, Oracle recognized Java Champion and former Oracle ACE Director. He founded a successful German conference himself and helps organize a number of conferences worldwide. He has contributed as a JavaOne content committee member for a number of years. In the interview he shares his expectations for the Java EE track this year.
On this note, I would like to make sure you know that the JavaOne content catalog is now already live with a few preliminary fairly obvious selections we were able to make. None of the sessions accepted at this stage are from Oracle speakers on our track. The folks that we selected early for acceptance include David Blevins, Jonathan Gillmore, Mohammed Taman, Rafael Benevides and Antoine Sabot-Durand. They will be talking about Java EE Connectors (JCA), Java EE 7 real world adoption, CDI and DeltaSpike. I would encourage you to check out all the early selections in the catalog. I also want to remind you that you can still save money by registering early for JavaOne.
I hope to see you at JavaOne. Do stay tuned for more interviews with committee members as well as some key speakers on our track.
Fortunately for the Java EE ecosystem, my good friend Bessem Hmidi has formulated just such a solution focusing on CDI as the back-end component model. He has aptly named his project AngularBeans and first release is now on GitHub for everyone to use. His simple hello world example speaks volumes as to the power of this solution. Beyond simply removing boilerplate AngularBeans does far more (look at the GitHub page for full details):
Bean Validation on the client side
Built-in internationalization support from server-side property files
Server-side event binding
He has a more comprehensive example that demonstrates all the capabilities of AngularBeans. The project is at a very early stage, so this is a great time to get involved! In particular Bessem is looking to improve the project documentation.
On a slightly separate note, Bessem is the JUG leader of the ESPRIT JUG in Tunisia. He is one of the key Java EE advocates in North Africa, along with the likes of Egypt JUG leader Mohamed Taman. Bessem and I both very recently spoke at the inaugural Voxxed Days Algiers, Algeria (expect the trip report from that great event soon!).
The JavaOne 2015 CFP is now closed. I want to thank all of those that submitted their thoughtful topics and all those who considered submitting. In the Java EE track we now have all the raw material we need to construct a strong selection. In the next few weeks we will be working hard with the review committee to carefully sort through all the submissions we have at hand.
I also want to take this opportunity to introduce you to the real decision makers in the track - the content selection committee members. The folks in the committee by far play the most important role in help shaping the track. This year on the track we are fortunate to have David Blevins, Cay Horstmann, Johan Vos, David Heffelfinger, Ryan Cuprak, Scott Sosna, Markus Eisele, Kevin Sutter, Linda DeMichiel, David Delabassee, Bruno Borges, and Harold Carr. You should get to know these folks if JavaOne is something you care about. I've posted their profiles on my personal blog. In the next few weeks, I plan to publish interviews with some of these folks through this humble blog.
Keep in mind that JavaOne is now already open for registration. I hope to see you all at JavaOne. In the meanwhile as always if you have any questions never hesitate to reach out.
Devoxx UK is fast approaching! The conference will take place in London at the usual venue (Business Design Center) in June. Devoxx UK is covering a broad range of topics and obviously Java EE will be well covered. Various Specification Leads and EG members will be present in London so it will be a good opportunity to catch-up. Here is a short overview of some of the Java EE related activities. For the full Devoxx UK agenda and additional practical details, see here.
The Adopt-A-JSR Summit will take place on Wednesday. This event, co-organized by the community and the JCP, will bring together Specification Leads, Java User Group, JCP leaders, OpenJDK leaders, Evangelists and conferences attendees in order to discuss how the community can be involved in shaping the future Java platform.
During the conference, several sessions will be devoted to Java EE:
As some of you know, the Chicago JUG has been doing a great job engaging with Adopt-a-JSR and Java EE 8. As part of that effort the JUG will host a virtual meeting on Google Hangout Tuesday, May 26 at 6:00 PM Central Standard Time (Chicago). Although the meeting is focused on the Chicago JUG because it is on Google Hangout, anyone is welcome to listen in! The session should also be recorded so you can view it later - stay tuned here. These are just some of the things that the meeting will cover:
Introduction to the JCP/JSR process
Status of the different Java EE 8 JSRs
The different ways in which JUG members can contribute
Live example (pick a JIRA, discuss and craft a reply, suggest a patch, try to recreate, raise a new JIRA)
The meeting will be led by none other than key Chicago based Java EE author and community advocate Josh Juneau. Folks that will attend in support include Chicago JUG leaders Freddy Guime and Bob Paulin as well as Heather VanCura of the JCP. Other folks from our team may also join in (I will sadly not be able to attend as I will be on a trans-Atlantic flight at the time :-(). Josh presented the Java EE 8 status update portion of the talk at the Chicago Coder conference very recently. His slide deck is now on SlideShare. I also spoke at the Chicago Coder Conference and will share the trip report in the next coming weeks.
In the meanwhile, you can find the details for the meeting on the Chicago JUG meetup page and the link to the actual Google Hangout is here.
Great news to our fellows bleeding edge Java EE developers and GlassFish users. We are now pushing two images of the application server to Docker Hub to make it even easier to try new and upcoming releases. The GlassFish organization is under registry.hub.docker.com/u/glassfish/, and here are the two images we have:
GlassFish Nightly Builds
This image is based on the latest builds of GlassFish, and updated when a new build is produced. To try this one, run:
# docker run -ti -p 4848:4848 -p 8080:8080 glassfish/nightly
This will give you the asadmin console. Start the domain with start-domain:
And access the console at http://localhost:4848. The default admin username and password are: user=admin / password=glassfish.
GlassFish Ozark - MVC RI
This image comes with GlassFish 4.1 modified with the required changes to run the new specification MVC 1.0, part of the upcoming Java EE 8 platform. To run this image, do:
# docker run -ti -p 8080:8080 glassfish/ozark
This will start GlassFish and deploy the Ozark Samples application. To access it, go to http://localhost:8080.
The @Context annotation gives, to a JAX-RS implementation, the ability to inject contextual information (e.g. Configuration, Security Context, etc. ) in a JAX-RS end-point. This capability is available since the early day of the specification, since JAX-RS 1.0. There are many scenarios where this feature is useful (e.g. access one of the HTTP header parameter of the consuming client).
To get more information, you can check the JAX-RS Specification (@Context is described in Chapter 9 & 10) or alternatively, you can read this 'Using @Context in JAX-RS' piece written by Abhishek Gupta (see initial instalment here).
The Java EE 7 Platform Specification (JSR 342) is currently going through a maintenance release process. If you check the proposed changes, you will see that this update is really about clarifying the specification itself; none of the proposed changes will impact the Java EE 7 RI nor the TCK. So clearly, only the specification itself will be slightly impacted.
It seems that a consensus has now been reached amongst the Java EE 7 Experts Group over the proposed changes and if everything goes well, the update will soon be submitted to the JCP to formally initiate the Maintenance Review process.
Chef is a popular open source infrastructure automation framework that has been popularized with the whole DevOps movement. In a nutshell, Chef has the notion of Recipe and Cookbook. A Recipe is written using a Ruby based DSL to describe how to install and configure software(s) on a host. And as the name suggest, a Cookbook is a collection of related Recipes.
Needless to say that managing Java EE Application Servers with Chef is a common use-case. You just need to use the appropriate Cookbook for your container : GlassFish, WebLogic, WildFly, TomEE, etc.
One of the key goals of CDI was to significantly improve Java EE platform extensibility at the core component level. Generic dependency injection alone goes a long way in making it fairly easy to integrate third-party components and libraries. CDI goes much farther by offering an entire portable extension API geared specifically towards writing CDI plugins. The most obvious manifestation of a resulting CDI ecosystem is plug-in collection projects like Seam 3 and it's successor DeltaSpike. However, there is actually a lot more to the CDI ecosystem, most notably tools (think IDEs) and larger projects that offer CDI pluggability.
So far there has not been a concerted effort to create a directory of sorts for the CDI ecosystem. While such a directory will (hopefully) never be completely all-encompassing it is helpful to have one place you could go to in order to find out all the plugins available for CDI. Most recently the CDI specification site added an ecosystem section to try and address this need. The page is looking pretty good already including listings like DeltaSpike, VRaptor, Vaadin, Camel, Forge and Arquillian - you should check it out. I can already see a few missing though like MyBatis/CDI, Agorava, Struts 2/CDI, Wicket/CDI, ZK/CDI and a few more (I'll reach out to the CDI folks to see why these might be missing). If you similarly see any CDI plugins that should be listed, you should try and reach out (the top of the CDI ecosystem page says how you can do so).
One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories. We have been doing just that for a long time through our adoption stories blog as well as JavaOne. JavaOne 2014 was particularly good in this regard and JavaOne 2015 looks to be even better. Indeed we hope the folks with great adoption stories that submitted last year but did not get accepted will resubmit next year. We will continue to highlight some of those sessions from JavaOne 2014 in the next few months. In this vein I'd like to highlight a very interesting real world story of practical usage of Bean Validation 1.1 in a Java EE 7 application at Harvard University.
Harvard University Institute for Quantitative Social Science's Dataverse application has been one of the earliest Java EE adoption use cases on GlassFish. They started with Java EE 5 and are now using Java EE 7 in the real world for a fairly complex application. The Dataverse application is an open platform for publishing, citing, analyzing, and preserving research data across universities. Although it started with Social Sciences, the application is now branching out to other fields such as Medicine and Astrophysics. The application makes full use of the Java EE stack including JSF and Bean Validation.
In their JavaOne 2014 talk project lead Gustavo Durand and senior developer Stephen Kraffmiller shared how they were sucessfully utilizing Bean validation in their Java EE 7 application. They shared some pretty advanced use cases and great practical insight. You can see their awesome JavaOne 2014 presentation below (if you are having trouble seeing the embedded video it is available here).
If you have a similarly great Java EE adoption story to share (particularly migration stories from other technologies), please do feel encouraged to share it through a JavaOne 2015 submission. The CFP deadline is April 29th, so you should hurry. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.
'Java API for JSON Processing 1.0' also known as JSON-P (JSR 353) is the standard JSON Processing API that was added in Java EE 7. JSON-P will be updated and that update (JSON-P 1.1 - JSR 374) should be included in Java EE 8. One of the goals of that revision is to add support for 2 JSON standards namely JSON Patch and JSON Pointer.
By nature JSON is simple and most of the standards in that space are simple as well. JSON Pointer and JSON Patch are 2 IETF RFCs that are closely related. JSON Pointer defines string syntax for identifying a specific value within a JSON document while JSON Patch defines a set (one or more) of operations to apply to a target JSON document. JSON Patch is leveraging JSON Pointer to specify where operation(s) need to be performed in the target JSON document. And a JSON Patch is in itself a JSON document. The most common pattern will be to apply a JSON Patch to transform a JSON document but it will also be possible to obtain a JSON Patch by comparing 2 JSON documents, the returned JSON Patch will then be a 'diff' between the 2 JSON documents.
It is the early day of JSR 374 but the EG is certainly making progress. At this stage, it is already possible to test, amongst other new features, JSON Pointer and JSON Patch as the early build of the JSR 374 RI already support those. Those tests would be a good place to look to understand how the API works. Note that at time of writing, the 'diff' method isn't yet implemented in the early JSR 374 RI build.
Getting feedback early on is really important for the various EGs! Make sure to look and test the various APIs that will, at some point, be part of Java EE 8.
This is a first and last reminder from us to all of the folks out there that the JavaOne 2015 CFP closes on April 29 - just about two weeks from now.
The procrastinator in you might be thinking two weeks is plenty of time. In reality if you haven't started working on your submissions yet, you are probably setting yourself up for some stress that will likely result in a weak submission. This is especially true if like most of us you will need to collaborate with others or get your boss's approval for your submission. Putting things in perspective the CFP has already been open for about two weeks so other folks already have a head start to maximize their chances of getting accepted. We want to make sure everyone in the community has a fair chance to help us build a strong Java EE track agenda by submitting their best ideas. As always, never hesitate to get in touch if you have a question.
Consider the following as inspiration for submissions to the Java EE track (the only real limits of course are your own imagination on anything in the Java EE ecosystem):
Existing and upcoming Java EE technology JSRs and implementations
Cool stuff that extends Java EE in new and interesting ways
Case studies using Java EE 5, Java EE 6 or Java EE 7 (specially migration from other technologies)
Best practices and design patterns for using Java EE technologies
Emerging trends in the ecosystem such as HTTP2, HTML5 and microservices
Insightful research, development and analysis work in server-side Java
Fortunately or unfortunately some previous JavaOne CFPs have been extended beyond their initial date. Please do yourself a favor and don't assume this will happen again. You may be winding up denying yourself a shot at submitting your great talk altogether :-).
Finally, here is that all important link to the CFP. Hope to see and accept your great topic soon :-)?
"If you don't vote you can't complain. Get involved." (David Blevins)
From the current set of Java EE 8 JSRs, 'Java EE Security API' (JSR 375) is the latest one as it was only approved in December last year. It was started later than the other JSRs. Nevertheless, the EG is now very active (+200 messages just for last month!).
Obviously, this effort need a strong focus as 'Security' can mean a lot of things. And depending on whom you ask, you will high likely have different views. So to EG is currently busy filtering and consolidating ideas. In addition, one thing that is clear is that having a common ground for discussions is really needed. So the EG is also working on defining a security API terminology; i.e. a common vocabulary to enable concise and accurate communication amongst the EG and the community (see here). This may sounds obvious but it's not; e.g. what's the difference between a user store and a user realm?
During JavaLand, some EG members have presented a few ideas that will be tackled in this JSR. Alex Kosowski (JSR375 Specification Lead) also presented, during Devoxx France, the plans for JSR 375. Alex's session recording will be made available in the coming weeks. In the meantime, you can check the slides.
Since there are potentially a lot of things that could be addressed in this JSR, the EG needs to make sure they address the right features, in the right order and in the right form. So the goal of those different sessions is really to expose the EG current plans and ideas but more importantly to get your feedback!
To know more, you should check this playground has it contains prototype ideas for possible inclusions in this JSR; lurk in the JSR 375 users mailing list and voice any relevant feedback!