Enterprise Java

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:

  1. 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
  2. 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)
  3. 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:

Reference: Possible Ways forward for MVC 1.0 from our JCG partner Ivar Grimstad at the agilejava.eu blog.

Ivar Grimstad

Ivar Grimstad is an experienced software architect focusing on Enterprise Java. He is participating in the Java Community Process as a member of the Expert Groups for JSR 368 (JMS 2.1), JSR 371 (MVC 1.0), JSR 375 (Java EE Security API). He is also a member of the NetBeans Dream Team.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Ed Burns
7 years ago

Regarding the TCK. For MVC, there is no TCK to let go of. So whomever might assume responsibility in your item 3 would more specifically be taking responsibility for producing the three required JCP artifacts: Spec, RI and TCK.

Ivar Grimstad
7 years ago
Reply to  Ed Burns

Cool!
Does that mean that it would be possible to change the proposed license for the TCK in the originan JSR?

Back to top button