OpenSource

Run and Debug a WildFly Swarm application from NetBeans

Java EE developers using NetBeans are used to be able to run and debug their thin-war applications in their application server of choice directly from NetBeans. When developing microservices packaged as über-or hollow-jars, you expect the same effortless way of running and debugging. The good news is that you can. In this post, I show step-by-step how to run and debug the WildFly Swarm version of CloudEE Duke in NetBeans.

Run WildFly Swarm application

The easiest way of running CloudEE Duke in NetBeans is to edit the Run project action for the project. Right click on CloudEE Duke, select properties and Actions as shown below.

Configure the Execute Goals to package wildfly-swarm:run, remove all the default properties and your’re all set. Run Project (F6 ) will start the application using the WildFly Swarm Maven Plugin.

Debug WildFly Swarm Appliction

To enable debugging, you follow the same steps as described above, but in this case it is the Debug Project action you select.

Execute Goals is configured the same way as for Run, but in the Set Properties, you need to configure a debug port for WildFly Swarm. This is done by setting the swarm.debug.port property, e.g. to 9000.

Debug Project Ctrl-F5 will start the application in debug mode. Note that the execution will halt while waiting for the debugger to attach. See the screenshot below for how it will look in the log.

Select Debug->Attach Debugger from the menu in NetBeans. Change the value for Port to 9000 (or the value you chose in the previous step) and click OK.

To verify the setup, set a breakpoint at line 16 in the class HelloWorldEndpoint.

Then navigate to http://localhost:8080/hello. The execution will stop at the breakpoint at line 16 in HelloWorldEndpoint.

The Relationship Between Jakarta EE, EE4J and Java EE

The Jakarta EE name has been out for about a month, and even if Mike Milinkovich explained the names and concepts pretty well in his blog post And the Name Is…, there still is a bit confusion about how it all relates and I get questions around it whenever the topic comes up. I have tried to sum up some of it here. Hope it helps!

Java EE

Java EE, or Java™ Platform, Enterprise Edition, is the name of the current platform governed by the Java Community Process (JCP). The latest version is Java EE 8, which was released in September 2017.

Jakarta EE

Jakarta EE is the name of the platform governed by the Jakarta EE Working Group. The first version will be Jakarta EE 8 which will be based on the Java EE 8 technologies transferred from Oracle to the Eclipse Foundation.

EE4J

Eclipse Enterprise for Java (EE4J) is the top level project in the Eclipse Foundation for all the projects for creating the standards that will form the base for Jakarta EE. The EE4J Project Management Committee (PMC) is responsible for maintaining the overall vision for the top level project. It will set the standards and requirements for releases and help the projects communicate and cooperate.

Summing Up

Jakarta EE does not replace Java EE! It is the name for the platform evolving with Java EE 8 as a starting point. Java EE 8 will still exist, but there will not be any new versions of the platform.

Jakarta EE does not replace EE4J! It is the name of the platform based on the EE4J projects with Java EE 8 as a starting point.

My vote goes to Jakarta EE !

I could probably write a long post about why my vote goes to Jakarta EE in the vote for new brand name to take over after Java EE, but it feels much more appropriate to refer to David Blevin‘s excellent description of the process in his blog post Java EE to Jakarta EE.

It has been tough on us keeping these discussions secret since we are all working for an open community and want to share everything. But the importance of securing a name that we as a community can trademark through the Eclipse Foundation makes it well worth the efforts.

A particular think I like about the Jakarta EE name is the significance of Apache Software Foundation and Eclipse Foundation working together for the best of the community.

 

Summing up 2017

2017 was an amazing year for me with a lot of speaking engagements at conferences in four different continents!

Per Lilja joined me in leading Javaforum Malmö and we managed to meet out target of four meetups each year. We are always looking for speakers, so don’t hesitate contact us if you want to present at one of our meetups.

Toward the end of the year, the EE4J PMC started up the work. The most pressing issue right now is to find a brand name to replace Java EE. Hopefully, this will be finalized in near future.

Stay tuned…

 

 

JavaZone 2017

I am very happy to be back at JavaZone in Oslo this year with a talk called MicroProfile – by Example. In this talk, I will describe the history and reasoning behind the Eclipse MicroProfile initiative, provide code samples and strategies for using all implementations and also introduce the newest addition to MicroProfile – MicroProfile Config.

Of course, there will be lots of demo and code…

 

MVC 1.0 is Back!

When Oracle announced that MVC 1.0 was withdrawn from Java EE 8, they also indicated that they were investigating a possible transfer to a community member or organization for completion as a standalone JSR. True to their word, a request for a transfer ballot of JSR 371 has now been submitted to the JCP Executive Committee.

I am happy to announce that I will be the receiving part of this transfer and thus will take over as Spec Lead for JSR 371.

So, why would I want to take over a JSR that ranked so low in the Java EE Survey?  Well, there are several reasons for that:

First of all the incredible community support and interest there is for MVC 1.0. For example, JSR 371 is the most widely adopted JSR by Java User Groups participating in the Adap-a-JSR program. No less than 8 JUGs have adopted this JSR!

Secondly, I feel that the wording of the question in the survey may have played a role. The question for MVC was “How important is MVC API for the next generation of cloud and microservices applications? (1=Not Important, 2, 3, 4, 5=Very Important)”.  Still, 505 responded Very Important and only 361 Not Important. The rest were pretty evenly distributed. See Java EE Survey Results for the complete numbers.

Third, only 1693 surveys were completed worldwide. Out of 10 million Java developers, this is an alarmingly low number taking into consideration that the survey was open for more than a month and there were massive encouragements for participation from the community, including Oracle.

Fourth, in the Java EE Guardians survey that was performed just prior to the Java EE 8 survey more than 30% of the respondents answered Very Important to the question “How important is it to add a new action-oriented MVC framework to Java EE?”.

The Way Forward

The most important thing right now is that the request for transfer is approved by the EC. The ballot closes January 30, so shortly after that the practical work may start.

Join the Java Community Process

You have probably noticed that the Java Community Process (JCP) has made becoming a member much easier. There is a new membership level called Associate Member which does not require any paperwork or approval of your employer and it can all be done online filling out a simple form.

https://jcp.org

Why should you become a member?

– It looks good on your resume
– You can join as a contributor to any JSR and help evolve the Java ecosystem
– You get a vote in the upcoming elections for the Executive Committee

Why is the last item important?

Well, I am running for an associate seat in the EC, so by joining the JCP and voting for me in the upcoming election, you make sure that your voice is heard at the very top level of the JCP. My motivation is to give as much power to the community as possible.

Let’s make the JCP Great Again!

 

Please feel free to contact me on Twitter or discuss in the comment section if you have any questions or comments.

Possible Ways forward for MVC 1.0

As mentioned in Aggressive Road Map for Java EE 8, MVC 1.0 is left out of the plans for Java EE 8.

The way I see it, and also have indications from several people I have talked with during JavaOne, the possible outcomes of this are:

1. MVC is dropped completely
2. MVC continues and is included in Java EE 8 (JSR 366)
3. MVC continues as a standalone specification outside of the Java EE 8 umbrella spec

Let’s cross our fingers that the survey result turns out positive for MVC and that option 1 is ruled out by the community.

If we’re honest, option 2 is probably not very likely to happen. Given the aggressive road map for EE 8, cuts will need to be made. And MVC certainly isn’t on the list of the preliminary proposal.

Then we are left with the third option. And I actually think this may be the best way for MVC. There are several reasons for this:

Release Cycle

MVC will not be depending on the Java EE 8 release and may release earlier and more oftenJava EE 8 is going to include some form of modularity and MVC may very well be one of these modules no matter if left out of EE 8. There are also some considerations to take if this option is explored

Portable RI

Ozark needs to be made portable across Java EE implementations. This means that we will need to get rid of the dependencies on internal Jersey APIs and base the entire implementation on APIs and SPIs that are available in Java EE 7 (and later Java EE 8 and 9)TCK

Licensing

An open TCK under for example Apache 2.0 will enable us to easier use community input for developing the TCK. If Oracle is willing to let go of the TCK, they will also be relieved of the cost of creating it. This actually also applies to Ozark. It would be great if it could be developed under e.g. Apache 2.0

So, what you should do is to fill out the survey by following the link below:

http://glassfish.org/survey

 

JCP EC 2016 Nomination

The Java Community Process (JCP) program 2016 Executive Committee (EC)
Elections have started. This is the first election to be held under the newest JCP 2.10 Process Document rules.

One of the new things introduced is that there will be two Associate Seats in the Expert Committee. These seats are elected by the Associate members of the JCP.

I have nominated myself for one of these Associate Seats. See my position statement below.

JCP EC 2016 Position Statement

7 reasons to upgrade to Java 7

Java 7 is finally here! Or to be absolutely correct, will be released July 28. In this post, I will point out 7 (wonder where I got that number from…) reasons to upgrade.

  1. Coins are also money
    Project Coin contains a couple of nice language changes that will make life as a programmer much easier. See the project page for details.
  2. Dynamic languages
    invokedynamic adds support for dynamically typed languages on the Java platform.
  3. New File System API
    File operations have always been pain in Java, but with this new API most of the issues are solved. Manipulating symbolic links for example.
  4. Concurrency
    The Fork/Join Framework provides a set of utilities you would benefit from when writing concurrent programs, giving the possibility for true parallelism on the Java platform.
  5. Modularization
    A refactoring enabling the Java SE platform to be downloaded as required by the VM as needed. 
  6. Enhancements
    A lot of enhancements regarding classloading, unicode, locale etc.
  7. It’s new
    And new things are always more motivating to work with than old, at least in the context of programming languages.

To be honest this is not very much for a major version of a programming language, especially since it has gone nearly five years since the previous version. But it shows that Java is still alive after the whole Oracle story.