Friday, June 22, 2018

Apache NetBeans 9.0 - How to Build & Run the Latest

In my last post, I spoke about how to obtain the Release Candidate of Apache NetBeans 9.0.  There have been some changes made since the Release Candidate (including the addition of a very nice updated splash screen), so in this post I will cover how to build and run the latest sources.  I really is quite simple to run the latest code...here's how:

1)  Clone the latest source code from the GitHub repository to your local machine:

git clone https://github.com/apache/incubator-netbeans.git

2)  Open your terminal and traverse inside of the cloned directory named "incubator-netbeans"

3)  Build the IDE using Apache Ant.  If you do not have it installed, please download from here: https://ant.apache.org/

To build, simply issue the "ant" command from within the "incubator-netbeans" directory.



4)  The build process will take several minutes, as it obtains all of the dependencies and performs the compilation process.  Once completed, open the incubator-netbeans/nbbuild directory, and you should see a directory entitled "netbeans".  Inside this directory are all of the files required to run the Apache NetBeans IDE.  You can run the IDE by invoking the incubator-netbeans/nbbuild/netbeans/bin/netbeans executable.


Once the executable is started, you will be presented with the new Apache NetBeans 9.0 splash screen, and you can then begin to use the latest build.



Monday, May 21, 2018

Apache NetBeans 9.0 - Release Candidate Review



First, I want to thank all of the developers that have been working hard on the Apache NetBeans 9.0 release.  I am on the mailing lists and these developers have been working around the clock to ensure that this release is solid.  I was part of the NetBeans 9.0 NETCAT testing team for the profiler tool this year.  I only contributed a few hours of testing, but it was a great experience to be part of the team helping to move NetBeans forward.  There are plenty of people who have contributed dozens of hours...so thank you!

Release Candidate 1 (currently in testing and not yet officially released) can be downloaded using the following links:

Build Artifacts:
https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-rc1-rc1

ZIP Artifact:
https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-rc1-rc1/incubating-netbeans-java-9.0-rc1-source.zip

This release of NetBeans constitutes all of the modules within the Apache NetBeans GitHub repository ((https://github.com/apache/incubator-netbeans).  These modules include the NetBeans Platform and the full IDE for Java SE development.

There are still a number of tasks that will need to be performed before moving forward, but Release Candidate 1 is a huge step.  In the coming days/weeks, there will likely be another release candidate which will include some final pieces, such as a new splash screen.  We are getting very close to the official Apache NetBeans IDE 9.0 release.

Keep in mind that this first release does not include the transfer of all NetBeans modules.  For instance, the Java EE modules have not yet been transferred or included in Apache NetBeans 9.0.  That transfer will occur sometime in the future.  However, it is still possible to develop Java EE applications using Apache NetBeans 9.0 by simply installing the Java EE related NetBeans 8.2 plugins.  I am doing this today and it works well!

Stay tuned during the coming weeks for the official release of Apache NetBeans 9.0.  In the meantime, get involved!  Please download the Release Candidate and take it for a spin.  Join the NetBeans developer mailing list to provide feedback and/or vote on upcoming release candidates.

https://netbeans.apache.org/


Wednesday, November 29, 2017

Easy Java EE Microservices with Payara Micro

Wondering how to get started with Java EE Microservices?  It only takes a few quick steps to deploy a Microservice using Java EE APIs.  Many think that Java EE is too heavyweight for use with Microservices, but that is simply not the case...especially if you only utilize the Java EE specifications that are required by your service.  In this brief post, I'll demonstrate how to quickly develop a Microservice with Java EE and then deploy to Payara Micro.

To download the example project, please go to GitHub: https://github.com/juneau001/SimpleService

For the purposes of this example, I will utilize NetBeans, but any Java IDE will suffice.  To get started, create a Maven web application and name it SimpleService.  Next, create two Java packages:  org.simpleservice and org.simpleservice.entity.  Once complete, the project should resemble the following figure:



Now many believe that a Microservice should not connect to an enterprise database, but I will leave that for those who wish to debate.  In this example, I will connect this service to a central Apache derby database to obtain data because I believe this to be a very likely scenario in many organizations.  In this case, we'll create a "Suggested Name" database web service, which will query a database table of suggested names for the upcoming EE4J platform.  To create the infrastructure, connect to a local Apache Derby database and create it using the following SQL:

create table SUGGESTED_NAME (
id numeric primary key,
name varchar(150));

insert into suggested_name values(1, 'Open EE');
insert into suggested_name values(2, 'Open JOE');
insert into suggested_name values(3, 'Cappucino');

Next, open the Maven POM file for the SimpleService project and add the following dependencies:

<dependencies>
        <dependency>
            <groupId>javax.ws.rs</groupId>
            <artifactId>javax.ws.rs-api</artifactId>
            <version>2.1</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>javax.persistence</groupId>
            <artifactId>javax.persistence-api</artifactId>
            <version>2.2</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>javax.validation</groupId>
            <artifactId>validation-api</artifactId>
            <version>2.0.0.Final</version>
        </dependency>
        <dependency>
            <groupId>javax.ejb</groupId>
            <artifactId>javax.ejb-api</artifactId>
            <version>3.2</version>
            <type>jar</type>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>eclipselink</artifactId>
            <version>2.5.2</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>org.eclipse.persistence.jpa.modelgen.processor</artifactId>
            <version>2.5.2</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.derby</groupId>
            <artifactId>derbyclient</artifactId>
            <version>10.14.1.0</version>
        </dependency>
    </dependencies>

Note that there is no Java EE dependency.  This is because I am utilizing only those dependencies that are required for the service.  Each dependency is added separately.

Next, create a package org.simpleservice.entity, and create an entity class named SuggestedName within it.  For brevity, I'm not going into all of the sources here, but you can check the sources out on GitHub (https://github.com/juneau001/SimpleService).

We'll need to implement our JAX-RS web service class next.  To configure the Java EE application for JAX-RS, let's create a class named ApplicationConfig and place it within the org.simpleservice package:
import java.util.Set;
import javax.ws.rs.core.Application;

/**
 *
 * @author Juneau
 */
@javax.ws.rs.ApplicationPath("rest")
public class ApplicationConfig extends Application {
    @Override
    public Set<Class<?>> getClasses() {
        Set<Class<?>> resources = new java.util.HashSet<>();
        resources.add(org.simpleservice.SuggestedNameService.class);
        return resources;
    }
}

Next, I'll create the JAX-RS web service class itself, and I will name it SuggestedNameService.  Here are the sources for the SuggestedNameService class.  Note that I have injected a Persistence Unit.  I will get to that next.


@Stateless
@Path("suggestedNameService")
public class SuggestedNameService {
    @PersistenceContext(unitName = "SimpleService_1.0PU")
    private EntityManager em;
    @GET
    @Path("{id}")
    @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
    public SuggestedName find(@PathParam("id") BigDecimal id) {
        SuggestedName suggestedName = null;
        try {
            suggestedName = (SuggestedName) 
                    em.createQuery("select object(o) from SuggesetedName o " +
                    "where o.id = :id")
                    .setParameter("id", id)
                    .getSingleResult();
        } catch (NoResultException ex){
            System.out.println("Error: "  + ex);
        }
        return suggestedName;
    }
   
    @GET
    @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
    public List<SuggestedName> findAll() {
        List<SuggestedName> suggestedNames = null;
        try {
            suggestedNames = em.createQuery("select object(o) from SuggestedName o")
                    .getResultList();
        } catch (NoResultException ex){
            System.out.println("Error: "  + ex);
        }
        return suggestedNames;
    }
    protected EntityManager getEntityManager() {
        return em;
    }
    
}

Since this service will connect to a database, I will create a persistence unit for the project.  This can be easily done in NetBeans by right-clicking the project and choosing New->Persistence->Persistence Unit.  Name the persistence unit SimpleService_1.0PU and use EclipseLink as the provider.  Do not add a data source at this point.

Once created, open the Persistence Unit and add the connection information.  In this case, I will connect to a JTA data source that I'll define next.  The data source is named DerbyDataSource, so the content of the Persistence Unit (persistence.xml) should look as follows:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="AuthorService_1.0PU" transaction-type="JTA">
    <jta-data-source>java:global/DerbyDataSource</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties/>
  </persistence-unit>
</persistence>

Create a web.xml deployment descriptor for the project.  If doing this within NetBeans, simply right-click the project and choose New->Web->"Standard Deployment Descriptor (web.xml) and click Finish.  Once the web.xml deployment descriptor has been generated, add the data source to it.

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
<data-source>
        <name>java:global/DerbyDataSource</name>
        <class-name>org.apache.derby.jdbc.ClientDriver</class-name>
        <server-name>localhost</server-name>
        <port-number>1527</port-number>
        <url>jdbc:derby://localhost:1527/acme</url>
        <user>acmeuser</user>
        <password>yourpassword</password> 
    </data-source>
</web-app>
That's it for the Java EE application.  You should now be able to compile the project into a WAR file and deploy to GlassFish, Payara, or another Java EE application server of your choice.  In this case, let's deploy to Payara Micro. 

To begin, download the latest Payara Micro JAR file from the website: https://www.payara.fish/payara_micro

Once downloaded, the server can be started up by opening a command prompt and executing the JAR with your local Java runtime by typing:

java -jar payara-micro-4.1.2.174.jar

To deploy the application (microservice) that we've created, simply utilize the --deploy option when executing the Payara Micro JAR, and point it to the SimpleService WAR file:

java -jar payara-micro-4.1.2.174.jar --deploy SimpleService-1.0.war

The SimpleService microservice can now be accessed via the following URL:  http://localhost:8080/SimpleService-1.0/rest/suggestedNameService




Saturday, November 04, 2017

Utilizing Apache NetBeans with JDK 9

Did you know that you can build Apache NetBeans from scratch today and utilize the latest JDK 9 features?  Here is how to do it:

Clone the NetBeans Incubator sources to your machine:

git clone https://github.com/apache/incubator-netbeans

Build using JDK 8 and Ant 1.9.9 by traversing into the cloned incubator-netbeans directory and invoking the ant build:

ant

Once the build is complete, traverse into the nbbuild/netbeans directory to see the resulting IDE build.  Run the IDE by invoking the executable or shell script contained within nbbuild/netbeans/bin.





Friday, September 08, 2017

Open EE: My Thoughts on an Open Java EE Platform

About two years ago, thousands of Java developers attended the JavaOne 2015 conference and learned about specifications and features that would be part of the Java EE 8 platform.  These features included the MVC 1.0 specification, Java EE Security 1.0, Microservices, CDI and more.  Java EE 8 was shaping up to be a great follow-up to the excellent Java EE 7 release.

After JavaOne 2015, progress and news around Java EE went silent.  In early January 2016, I received an invite to a Slack group that was created by some members of the Java EE community.  On the Slack channel, there were discussions around the halt of Java EE, and what the community may be able to do in order to keep it moving forward.  I was humbled by the sense of community from the members of the channel and the devotion to the platform was very evident.  Not long after, the Java EE Guardians were formed, focusing on publicizing the stall of Java EE.  The group put forth effort pressuring Oracle to make a statement and continue moving Java EE forward.  Especially in this fast paced space, looming silence regarding the future of any technology can be taxing on those involved.  Others worked on the Java EE specifications as much as possible, making strides forward.

After almost a year of silence, we started to hear music around Java EE again, and at JavaOne 2016 Oracle unveiled the plan to continue moving Java EE 8 forward, albeit a bit differently than originally planned.  The newly envisioned Java EE centered around Microservices and dropped a few of the specifications that no longer fit into the puzzle.  MVC 1.0, JMS 2.1, and Management 2.0 were taken out of the picture, while the newly proposed Health Checking and Configuration APIs were added.  MVC was eventually handed over to the community, which I think was a great move.  The Health Checking and Configuration APIs, which were clearly aimed toward microservices support, were later taken out of the picture for Java EE 8 due to lack of time.  Java EE 8 had more community involvement than any previous Java EE release, and much of this is likely due to the hiatus.  Java EE 8 moves forward, albeit a bit more lean than originally planned, we are moving forward.

Now, nearing the JavaOne 2017 conference, we are on the heels of a Java EE 8 release.  This release includes much of the original core Java EE 8 plan, bringing the Java EE platform in-line with Java SE 8.  It also enhances CDI support throughout the specifications, brings forth Security 1.0, which is long overdue, and JSON-B, closing the JSON to Java conversion gap that was left after JSON-P was released.  Java EE 8 will be a solid release, and I am thankful to all who are involved in making it happen.  I am sorry to say that I will not be at the JavaOne conference this year when it will likely be released, but I know that my colleagues will keep me in-tune with the latest news coming from the conference!  If you are going, make sure you check out the many great Java EE talks that will be presented.

Almost like a professional sports superstar going out on a high note, Oracle recently announced that they are planning to open source Java EE.  I have to applaud Oracle for all of the great work they've done and the support that they've given to Java EE through the years.  I am hopeful that they will remain engaged even after Java EE is open sourced, as they are a very important player in this space.  In my mind, they chose a perfect time to announce the opening of Java EE, as the Java EE 8 release will mark a great milestone making Java EE even more productive and relevant as one of the top application development platforms in the industry.  The community around Java EE seems as though it has never been more engaged than it is now.  Over the years since the cumbersome J2EE morphed into the productive platform that we call Java EE today, the community has continued to grow by the thousands.  The Java EE Guardians have thousands of supporters, each of them hoping to help move Java EE forward for years to come.

I see a great future for an open Java EE.  However, many questions are left to be answered.  Will the JCP still be used to manage the changes that are proposed for the platform?  Perhaps this is one of the questions that has the potential to impact the platform the most.  If the JCP will still be used to manage the platform, can it be changed in such a way that it will be conducive to a faster moving platform?  Do we want Java EE to become a faster moving platform, much to the likes of other frameworks such as Spring?

One of the main strongholds of Java EE is standardization.  If the open Java EE were to become more dynamic, can it maintain its place as a standard in the industry?  I think so.  I think that ideally the JCP could still be used to move the specifications forward, with a bit of a modernizing on the approach.  I like the idea of having shorter Java EE release cycles with fewer changes in each release.  Such an approach can really help the platform to retain its relevancy in this fast moving space.

What are your thoughts on the opening of Java EE?  I welcome it and look forward to seeing what is to come for JavaOne 2018.

Wednesday, July 26, 2017

Java EE 8: Start Testing Today

Java EE 8 will be finalized and ready for public use soon.  There is no better time to get started testing the new features than now.  You can do so by grabbing a copy of my Java EE 8 Playground project and deploying to GlassFish 5.

I've just updated the project to repair bugs and include better formatted table data within the tables.  I've also added a couple of examples:

- JSON-B example: Allows one to fetch the JSON for customer objects.

- CDI 2.0 Async:  Add a new Job object to see async event output in server log

GitHub Project:  https://github.com/juneau001/JavaEE8-Playground

Saturday, June 10, 2017

Java 9 Recipes Published!

A bit ahead of schedule, my latest book entitled Java 9 Recipes: A Problem-Solution Approach, has just been published!


This book is the 3rd Edition in the Java Recipes series.  It covers all of the information that was in the previous editions, including the new content for Java 9.  Specifically, you will learn how to use new Java 9 features including:


  • Modularity
  • Private Method Implementations in Interfaces
  • Process API Enhancements
  • New Streams API Enhancements
  • HTTP/2 Client API

I'd like to thank Apress for providing me with the opportunity to help share my knowledge of the Java platform.