Oracle CodeOne (JavaOne) Proposals for 2018

Thinking of presenting at a conference? I have been fortunate to speak at JavaOne these past four years. This year I will be presenting at ApacheCon in Montreal in September. What follows are the three presentations that I just submitted to CodeOne, the successor to JavaOne. I won’t know till mid June if any will be accepted. If you are thinking of submitting a proposal then my examples may help. If you see a change I should make, its May 2 and the deadline is May 10, then let me know.

Don’t answer the phone during your screen cast!

Yes, it happens, though, it might work if I could hear both sides of the conversation. Video instruction is fast surpassing the written word as a way to share what we learn with the community. Every laptop has a camera and microphone, so you are all set. Not so fast, there are a number of things you need to do to make a successful video or screen cast. In this session we will discuss the most common errors made and how to prevent them. You do not need to set up a studio in your home or workplace but there are a range of things you can do to make your screen cast watchable. And don’t forget, turn off the phone before you start recording.

Submitted as a Birds of a Feather session in the Developer Community

Running our Robot Overlords with JakartaEE

The Raspberry Pi is widely used as the brains of many a robotic project. Sadly, Java is not usually considered as the language to program our overlords. In this presentation we will review my experiments to develop a simple control system for a GoPiGo educational robot car. Using Enterprise Java, JakartaEE, microservices and JSF web applications can remotely control the car. Turning the car into a smart car can now be coded in the remote controller computer or directly as part of a web application. These same techniques can be used to control any Pi based project. All hail our Java-based robot overlords.

Submitted as a Developer Session in the Java Server-Side Development and Microservices

Got a gig teaching Java? You should be using Apache NetBeans in the classroom.

You just got a part time gig teaching Java at a local school or college. You have a good sense of what you plan to teach but which IDE should you use? Should you even use an IDE? The answer is quite simple, use Apache NetBeans. As an IDE NetBeans requires a user to know only a handful of commands. As the student’s skills increase more features of NetBeans can be revealed. Using the other IDEs out there require a significant investment in learning how to use them. It requires you to spend too much time doing technical support for the IDE. In this session I will explain why you should be teaching with NetBeans and, by extension, why you should be using it in the workplace.

Submitted as a Birds of a Feather session in the Development Tools

Password Confirmation on a JSF Page – Part 2 An Entity Model

Kyle Stiemann from the Liferay Faces Team was kind enough to point out a flaw in the Java Server Faces libraries prior to versions JSF 2.3 and Mojarra 2.2.16 related to what I am presenting here. The solution requires two changes. The first is an addition to the web.xml file that you will see commented about in the file. The second change requires using newer versions JSF. Payara 4/Glassfish 4 manifests the problem. Payara 5/Glassfish 5, with the newer library, does not exhibit the problem. You can read about the problem at: JSFSPEC-1433 issue

Welcome to part 2 of 2 articles on confirming password entry into a JSF form. You should read part 1 at to understand how I got to this point. In this example rather than a plain bean we will use the JPA with an Entity bean and a JPA controller as generated by my IDE of choice, NetBeans 8.2. In addition to using the JPA to save the login name and password, there is a new validator to ensure that the login name does not already exist in the database.

To run this code you will need MySQL or other SQL database. The scripts for creating the database and table are in src/test/resources. These must be run before you can execute the code.

You can download the project at

To begin with let’s look at the NetBeans 8.2 generated Entity class:

import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;

@Table(name = "user_table", catalog = "JSF_PASSWORD", schema = "")
public class User implements Serializable {

    private static final long serialVersionUID = 1L;
    @Basic(optional = false)
    @Size(min = 1, max = 45)
    @Column(name = "LOGIN_NAME")
    private String loginName;
    @Basic(optional = false)
    @Size(min = 1, max = 12)
    @Column(name = "PASSWORD")
    private String password;

    public User() {

    public User(String loginName) {
        this.loginName = loginName;

    public User(String loginName, String password) {
        this.loginName = loginName;
        this.password = password;

    public String getLoginName() {
        return loginName;

    public void setLoginName(String loginName) {
        this.loginName = loginName;

    public String getPassword() {
        return password;

    public void setPassword(String password) {
        this.password = password;

    public int hashCode() {
        int hash = 0;
        hash += (loginName != null ? loginName.hashCode() : 0);
        return hash;

    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof User)) {
            return false;
        User other = (User) object;
        if ((this.loginName == null && other.loginName != null) || (this.loginName != null && !this.loginName.equals(other.loginName))) {
            return false;
        return true;

    public String toString() {
        return "com.jsfpasswordconfirm.entities.UserTable[ loginName=" + loginName + " ]";

This entity class is not under the management of CDI. Therefore the backing bean will be responsible for creating the entity bean in the getUser() method. The JPA controller class will be managed by CDI and is injected into the backing bean.

You should take note of the fact that JSR-303 Bean Validation annotations are used. Specifically, each field has an @Size annotation that comes from JSR-303. The same validation is also present on the JSF form using f:validateLength. Here is where I stumbled across an unusual behavior.

When I leave the fields blank I trigger the JSF required validation and the appropriate message from the bundle is displayed. When I exceed the length of the fields, 45 for login name and 12 for password something unusual occurs. I get two messages, one from the JSF validator and one from JSR-303. This does not make sense to me because I expect the JSR-303 validation to occur only if the JSF validation is successful and we apply the UI elements to the model. Searching for why this is occurring has not turned up a reason. If you know why this is happening please let me know.

Double validation message

There are two ways to handle this problem. The first is to remove all validation from the JSF form that matches a JSR-303 validation and only have JSR-303 validation in the bean. While this works it moves the validation away from the user interface. I prefer to validate closer to the user. The opposite approach, remove the JSR-303 validation from the bean, should never be done. Entity beans are filled not just from the user interface but from the database and possibly other classes in the application. There must be bean validation.

The solution I discovered is simple. You can prevent bean validation from occurring by adding:

<f:validateBean disabled="true" />

You only need to add this to the login name and password. The password confirm field is not in the entity so it is not subject to JSR-303 validation. Here is the JSF page.

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns=""

        <h:outputStylesheet library="css" name="styles.css" />
            <h:panelGrid columns="3" cellpadding="1" border="0" cellspacing="10"
                         title="#{msgs.signup}" columnClasses="firstColumn,secondColumn,thirdColumn"
                         rowClasses="rowHeight, rowHeight">
                <f:facet name="header">
                    <h:outputText value="#{msgs.signup}" />

                <h:outputLabel for="login_name" value="#{msgs.login_name}"/>
                <h:inputText id="login_name" 
                    <f:validateLength maximum="45" />
                    <f:validateBean disabled="true" />
                <h:messages for="login_name" styleClass="message" />

                <h:outputLabel for="password" value="#{msgs.password}"/>
                <h:inputText id="password" label="#{msgs.age}"
                    <f:validateLength maximum="12" />
                    <f:validateBean disabled="true" />
                <h:messages for="password" styleClass="message" />

                <h:outputLabel for="password_confirm" value="#{msgs.confirm}"/>
                <h:inputText id="password_confirm"
                             validator="#{passwordBacking.validatePasswordCorrect}" >
                    <f:validateLength maximum="12" />
                <h:messages for="password_confirm" styleClass="message" />

            <h:commandButton id="saveButton" value="#{}"

I have added one additional validator. The login name is the primary key. Therefore, it is necessary to test if the login name is already in the database.


In the backing bean I have added the method validateUniquePassword. Here is the updated backing bean.

import com.jsfpasswordconfirm.controller.UserTableJpaController;
import com.jsfpasswordconfirm.entities.User;
import javax.enterprise.context.RequestScoped;
import javax.faces.application.FacesMessage;
import javax.faces.component.UIComponent;
import javax.faces.component.UIInput;
import javax.faces.context.FacesContext;
import javax.faces.validator.ValidatorException;
import javax.inject.Inject;
import javax.inject.Named;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class PasswordBackingBean implements Serializable {

    private final static Logger LOG = LoggerFactory.getLogger(PasswordBackingBean.class);

    private UserTableJpaController controller;

    // The entity object
    private User user;
    // The value for the confirmPassword field that does not exist in the entity
    private String passwordConfirm;

    public User getUser() {
        if (user == null) {
            LOG.debug("Creating new User entity object");
            user = new User();
        return user;

     * Save the current person to the db
     * @return
     * @throws Exception
    public String createUser() throws Exception {
        LOG.trace("Creating new User entity object");
        return "doSomething";

    public String getPasswordConfirm() {
        return passwordConfirm;

    public void setPasswordConfirm(String passwordConfirm) {
        this.passwordConfirm = passwordConfirm;

    public void validatePasswordCorrect(FacesContext context, UIComponent component,
            Object value) {


        // Retrieve the value passed to this method
        String confirmPassword = (String) value;

        // Retrieve the temporary value from the password field
        UIInput passwordInput = (UIInput) component.findComponent("password");
        String password = (String) passwordInput.getLocalValue();

        LOG.debug("validatePasswordCorrect: " + password + " and " + confirmPassword);
        if (password == null || confirmPassword == null || !password.equals(confirmPassword)) {
            String message = context.getApplication().evaluateExpressionGet(context, "#{msgs['nomatch']}", String.class);
            FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, message, message);
            throw new ValidatorException(msg);

    public void validateUniquePassword(FacesContext context, UIComponent component,
            Object value) {


        // Retrieve the value passed to this method
        String loginName = (String) value;

        LOG.debug("validateUniquePassword: " + loginName);
        if (controller.findUser(loginName) != null) {
            String message = context.getApplication().evaluateExpressionGet(context, "#{msgs['duplicate']}", String.class);
            FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, message, message);
            throw new ValidatorException(msg);


As mentioned earlier in this article the getUser() method creates the User entity, it is not injected. The validateUniquePassword method calls upon the JPA controller’s findUser method that either returns an entity or a null reference.

Everything is in place now. The form now validates that there is input in the fields, validates the length of the fields, validates that entry of the password in the two password fields is the same and validates that the login name will be unique in the database.