- Java EE Webinar Replay
- Putting Hypermedia Back in REST with JAX-RS
- Java Community Event in Japan
- Java Euro Tour
- New Java Champion Mark Heckler
- NightHacking Tour in Japan
- Microservices Hackathon
- New Java Champion Ivar Grimstad
- Java ME Embedded 8.3 Release
- Step-by-Step High Availability with Docker and Java EE
Wednesday May 25, 2016
Tuesday Sep 02, 2014
By Yolande Poirier-Oracle on Sep 02, 2014
By Guest Blogger Reza Rahman
For the Java EE track at JavaOne 2014 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference.
To this end we recently interviewed Greg Wilkins. Greg is the mastermind behind Jetty and a long-time key contributor to the JCP, particularly for the foundational Servlet specification. In fact Greg is likely to be instrumental in the upcoming Servlet 4 specification slated to be included in Java EE 8. He will likely be the only person in the Servlet 4 expert group that is also part of the IETF HTTP 2 working group. We wanted to talk to Greg about his Jetty/Servlet sessions at JavaOne 2014 and HTTP 2 generally:
font-family: Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px;">Greg has several sessions on the track that he talked about:
- Jetty Features: In his open-ended Birds-of-a-Feather session, Greg will share the latest features added and to be considered in Jetty.
- Into the Wild with Servlet Async IO: In this deeply technical session, Greg will be exploring the ins-and-outs of the Servlet 3.1 asynchronous I/O feature. If this is a topic that interests you, the session is probably your best opportunity to gain knowledge from a true subject matter expert.
Bear in mind, Oracle's own Ed Burns will have a detailed session on Servlet 4/HTTP 2. Besides Greg's sessions, we have a very strong program for the Java EE track and JavaOne overall - just explore the content catalog. If you can't make it, you can be assured that we will make key content available after the conference just as we have always done.
Tuesday Aug 14, 2012
By Janice J. Heiss on Aug 14, 2012
Bien explains the basics:
“LightView uses the HTTP (REST) protocol to communicate with the back-end server. For the realization of back-end communication, an external library—the Jersey client—is used. LightView connects with the back end (LightFish) at startup time, so it is not suitable to lazy-load the Jersey dependencies for optimization purposes. Furthermore, multiple JAR files are hard to handle for standalone applications; you have to set up the class path correctly and keep all the moving parts consistent. The most convenient way to deploy Java (and JavaFX) applications is simply by starting them with java -jar my-killer-app.jar and deploying a single file that contains all the dependencies.”
He shows how the class files are packaged with the javafxpackager, which is shipped with the JavaFX 2 SDK, using the exec-maven-plugin and explains the core tasks achieved by Maven and describes the what javafxpackager does behind the scenes. He then shows how the LightView application operates and interacts with LightFish.
Bien concludes by emphasizing that the richness of JavaFX lies in the fact that it is another Java library. “Because JavaFX is ‘just’ an additional Java library, all of the established build, test, and deployment infrastructure can be reused. You can develop JavaFX applications using any integrated development environment (IDE) you like. And best of all, you can use a single language in a project, from the Java EE back end to the JavaFX front end.”
Check out the article here.
Insider News from the Java Team at Oracle!