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

 

MVC 1.0 Generator

The JPA Modeler plugin for NetBeans provides visual support for creating, designing and editing entity relationship models. It also provides Java code generation and new for version 1.5.5 is that it provides support for generating MVC 1.0 applications.

Check out MVC 1.0 Generator Tutorial to see how it works.

JSP

Kudos to Gaurav Gupta (@jGauravGupta) for this awesome tool! Another proof that NetBeans is the IDE for developing Java EE applications!

Follow @jpamodeler on Twitter!

NetBeans Dream Team

It is great to start 2016 with the announcement that I have been included in the NetBeans Dream Team!

I always try to be as objective and unbiased as possible when writing and talking about tools and technologies, but I guess it has been pretty obvious that NetBeans is my favorite IDE and in my opinion the best IDE for Java EE development. Being a member of the Dream Team will enable me to contribute even more to make this great tool even greater.

More information about the NetBeans Dream Team can be found on the wiki.

Snoop becomes SnoopEE [ˈsnuːpı]

SnoopEE [ˈsnuːpı] The lean and simple discovery mechanism for Java EE based microservices.

What’s in a name, really?

Naming is hard! When I came up with the name Snoop for my discovery mechanism for microservices based on Java EE, my though was to associate the name with snooping around for services to discover”. It seems, however, that most people’s thought goes to Snoop Dogg when hearing the name and that was never my intention.

That is one of the reasons for the renaming. Another consideration is that I want to point out that the best fit for SnoopEE is for Java EE!

At the same time I don’t want to signal that it is only for Java EE. I want it to be just as lean and simple no matter what technology used to implement the services. That is the only reason why I have been a little reluctant to the renaming.

SnoopEE has a nicer feel and as the twitter poll indicates, I am not alone thinking this.

For the record, I have nothing at all against Snoop Dogg! I just feel that Snoopy the dog is a little bit cuter…

I have crated a new page for SnoopEE, but as for everyhing else, such as GitHub repo, maven coordinates and naming, it all stays as it is until properly announced otherwise.