java – Page 10 – Kev's Development Toolbox

February 11, 2020February 11, 2020

What happened to the proliferation of Java web frameworks from the early 2000s?

Back in the early 2000s if you were a Java developer working on building web apps, chances are you were using Apache Struts. It was the de facto, go-to web framework of it’s time, pretty much used everywhere by everyone (it was even noticeable online for it’s pattern of using ‘*.do’ URLs for its Actions). However, it wasn’t the only framework in town. Around early to mid 2000s there was an explosion of Java based web frameworks being developed, for a while it seems like it was the-thing-to-do to build your own web framework because after all, you know better than all the other guys right?

Joking aside, other major frameworks that appeared, some of the other big names were Wicket, Cocoon, Tapestry, Webwork (Webwork and Struts merged to form Struts 2), GWT and Vaadin. In the Java EE space the standard web framework became JSF but never really gained traction over any of the others. The one that stayed the course and probably the only one still in serious usage would be Spring Web MVC.

The funny thing about all this churn that occurred is that it feels like it’s all happening again, but now in the Javascript space. Sure, once we realized we could could offload some of this backend rendering of the UI to the frontend and after Google had shown the way with GMail showing us how the user experience of a single page app is far better than the traditional request/response of web apps we had become used to, it was inevitable that serverside based Java web frameworks would fall out of favor and get replaced by Javascript clientside frameworks. Was it inevitable that the industry would go through the same learning pains once again though? I’m not sure, but it happened.

At one point jQuery was the de facto JavaScript framework, much like Struts was in the Java space back in it’s time. Then came the flood: backbone, ember, Dojo, Knockout seemed to to be the main players, eventually settling down to ‘the big 3’ that we have today, Angular, React and Vue.

So what happened to all the Java web frameworks? Spring Web MVC is still around and still in use. With the change in technologies and a shift in focus from backend web frameworks to frontend, the backend web frameworks became less relevant. Could this shift happen again? Sure, when the next big things comes along.

Moral of the story: tech changes quick in software development. Keep an eye out for whats coming next, because what’s hot today can quickly become irrelevant tomorrow.

Additional reading: if you’re interested to read more about Java web frameworks, Zeroturnaround’s Rebel Labs used to do a survey on framework usage, and you can see their findings from their relatively recent reports, from 2014, 2015 and 2017:

https://www.jrebel.com/blog/java-tools-and-technologies-landscape-2014#Web%20Frameworks

https://www.jrebel.com/blog/java-web-framework-usage-stats

https://www.jrebel.com/blog/java-web-frameworks-index

September 14, 2019September 14, 2019

Deploying a Jersey based web app to WildFly 8 (part 1)

I’ve been resuscitating a personal Amateur Radio related project from a few years back that I previously had hosted on RedHat’s OpenShift. It was previously deployed on WildFly 8, so before I start making changes I want to get it deployed again locally on WildFly 8.

First up I got this error:

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ServiceLocator with qualifiers @Default at injection point [BackedAnnotatedField] @Inject private org.glassfish.jersey.internal.inject.ContextInjectionResolver.serviceLocator

This error appears to be pretty common. From the suggestions posted in reply to a similar post to WildFly forum here, the suggestion was to include Glassfish dependencies. I never had these included before, so not sure why I need these now, but these did the job:

<!-- kh added for error: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default -->
<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>17.0</version>
</dependency>

<!-- kh: added per: https://developer.jboss.org/thread/240847 -->
<dependency
  <groupId>org.glassfish.jersey.containers.glassfish</groupId>
  <artifactId>jersey-gf-cdi</artifactId>
  <version>2.14</version>
</dependency>

<dependency>
  <groupId>org.glassfish.jersey.containers</groupId>
  <artifactId>jersey-container-servlet</artifactId>       
  <version>2.14</version>
</dependency>

The odd thing is if I deploy to WildFly 8.2 I don’t get this error or need these additional dependencies. Anyway, all set for now. I just tested deploying to 17.0.1 with no additional changes needed either.