Monday
#Duke'sCafe
After the breakfast at our hotel, we took off to Hilton Hotel where Duke's Cafe was set up. Taylor Street between O'Farrell and Ellis Street was closed to enable the setting up of Duke's Cafe, what an awesome set up. The Cafe is an open air lounge with coffee stations (they serve beer after lunch - yay!) where one can relax in between the sessions, load up on caffeine and catch some fresh air. I finally understood why Phillip made a fuss about it on Saturday when no signs of the set up was in please; on his previous visits to JavaOne it was set up at Mason Street, so we kept looking there. The picture below shows the cool Duke's Cafe setup, more pictures will be available on my Google+ account, so keep watching.
Null pointer exceptions, unintended side effects, SQL injections, concurrency errors, mistaken equality tests, and other runtime errors. This presenter showed us how to guarantee, at compile time, that these runtime exceptions cannot occur.
Apparently the Java's type system is too weak. The compiler's type checking prevents many errors, however, it doesn't prevent enough errors. The presenter showed few examples were the Java compiler thinks your code is OK, therefore not warning you of a possible runtime crash, leaving you to find out at runtime, ouch!!! For many this might not be a problem but if you are running a mission critical systems, these might cause loss of income or even more severe, loss of life. An example of a Java statement that the compiler type checker thinks is OK but crashes at runtime:
Apparently the Java's type system is too weak. The compiler's type checking prevents many errors, however, it doesn't prevent enough errors. The presenter showed few examples were the Java compiler thinks your code is OK, therefore not warning you of a possible runtime crash, leaving you to find out at runtime, ouch!!! For many this might not be a problem but if you are running a mission critical systems, these might cause loss of income or even more severe, loss of life. An example of a Java statement that the compiler type checker thinks is OK but crashes at runtime:
Collections.emptyList().add("one"); //java.lang.UnsupportedOperationException
An empty list is immutable, hence the runtime exception. The presenter went on to show many examples, some found in many popular libraries that every developer depends on like JUnit, Google GSON and many more open source projects. The good news, all of these can be prevented by The Checker Framework. The library enhances Java’s type system allowing developers to detect and prevent errors in their Java programs. It is a compile time dependency (library) and includes compiler plug-ins ("checkers") that find bugs or verify their absence. All the developer needs to do is annotate their class with some annotations similar to the populate @NonNull used by many frameworks for preventing the null pointer exceptions. There are many annotations ("checkers") provided by the framework for different checks. Below are some of the "checkers":
- @NonNull - prevents null arguments in a method
- @Nullable - warns the implementer of the method that the argument can be null
- @Regex - validates regular expressions input
The framework is extensible, developers can easily write their own checkers to prevent errors not covered out of the box by the framework. A more detailed tutorial can be found on the framework's website. Since the framework has exposed bugs in Google GSON library, Google uses this framework on some of their libraries to prevent errors.
#JavaEE8WorkInProgress...
Linda DeMichiel, Java EE Specification Lead, presented to us the Java EE features that will be up coming with the Java EE 8 release; what a great presentation. A disclaimer was put forward that the material she was presenting was subject to change, hence the title. If you are not yet in Java EE 7 then eat your heart out, because Java EE 8 is going to make the even better and makes the developer's work easier, it promises lot less boilerplate code.
The changes were driven by the community feedback. A survey was made where Java EE developers world-wide indicated where they require changes. The proposed Java EE changes will follows these themes:
- HTML 5/Web Tier enhancements: JSON B 1.0, JSON P 1.1, Server-sent Events (SSE), MVC 1.0 (component & action-based), HTTP/2 & Servlet 4.0
- Ease of Development /CDI alignment: Security Interceptors, Simplified messaging with JMS MDBs, JAX-RS Injection alignment, WebSockets scopes, Pruning of EJB 2.x client view and IIOP Interoperability
- Infrastructure for running in the Cloud: Java EE Management 2.0, Java EE Security 1.0
HTML 5/Web Tier enhancements:
- JSON B 1.0: an API to marshal/unmarshal Java objects to/from JSON. Similar to JAX-B runtime in the XML world. This will draw from the best practices of existing JSON binding implementations, such as, MOXy, Jackson, GSON,etc. It will allow switching of JSON binding providers. It will also allow default mapping of classes to JSON - annotations to customise default mappings. JsonBuilder; client's entry point to JSON binding API; it will provide operations for selecting provider implementation. Jsonb; an abstraction over JSON binding framework operations; created using JsonBuilder. fromJson(); to read JSON input and unmarshal to Java object content tree. toJson(); to marshal Java object to JSON output.
- JSON P 1.1: will keep JSON P specification up-to-date. It will track new standards (JSON Pointer - IETF RFC 6901, JSON Patch - IETF RFC 6902). This version of JSON P will add editing operations to JsonObject and JsonArray (JSON Query using lambdas); and also the helper classes and methods to better utilise Java SE 8's stream operations.
- Server-sent Events: it is part of the HTML 5 standard. Server-to-client streaming text data (not to be confused with WebSockets, SSE is only a push). Mime type is "text/event-stream". Long-lived HTTP connection. JAX-RS is the natural fit for this; streaming HTTP resources already supported; Small extension (Server API: new media type - EventOutput; Client API: new handler for server events); Jersey (JAX-RS Reference Implementation) already supports SSE.
- MVC 1.0: 2 main styles to be specified. Component-based MVC; style made popular by component frameworks (JSF, Wicket, Tapestry, etc.). The controller is provided by the framework. Action-based MVC; controllers defined by the application, the style made popular by Struts 2 and the Spring MVC. The controller dispatches to a specific action, based on the request information. Each action performs a specific task, possibly updating the model tier along the way.
- HTTP/2 and Servlet 4.0: addresses the limitations of HTTP 1.1. HTTP 1.1 uses TCP poorly; TCP was built for long-lived flows, HTTP flows are short and bursty. The Web performance mantra is “avoid HTTP requests” because HTTP 1.1 make them expensive. This caused the following workarounds to be established by developers: Sprites, Domain sharding, inlining and file concatenation. With HTTP 2, this workarounds won't be required, because of the goals of HTTP 2 is to address the Head-of-line (HOL) blocking problem using the Request/Response multiplexing over a single connection. HTTP 2 is binary instead textual; binary protocol are more efficient to parse. The HTTP 2 features stated above will be supported through Servlet 4.0.
Ease of Development /CDI alignment
-
Security Interceptors: intercept at access enforcement points - POJO method.
-
JMS message-driven beans: the ease of development for JMS started with JMS 2.0; the upcoming JMS 2.1 will simplify things even more. API for receiving messages asynchronously will be improved.
-
JAX-RS injection alignment: will keep JSON P specification up-to-date. It will track new standards (JSON Pointer - IETF RFC 6901, JSON Patch - IETF RFC 6902).
-
WebSockets scopes: will keep JSON P specification up-to-date. It will track new standards (JSON Pointer - IETF RFC 6901, JSON Patch - IETF RFC 6902).
-
Pruning of EJB 2.x client view: will keep JSON P specification up-to-date. It will track new standards (JSON Pointer - IETF RFC 6901, JSON Patch - IETF RFC 6902).
Infrastructure for running in the Cloud
-
Java EE Management 2.0: to provide REST-based APIs for Management and Deployment.
- Java EE Security 1.0: standardize role service - role mappings can be stored in app-specified repository (e.g. LDAP), without the need to access server configuration. User management - allow application to manage its own users and groups. Standardized syntax for password aliases - avoid storing passwords in clear text in code, deployment descriptors, files, etc.
More details on the proposed changes can be found the Java EE JSR site.
This was nice precursor for my next sessions through out the day; all other sessions on the day went into finer details on the some the topics already covered by this session. These included:
- HTTP 2 - in the session named: HTTP/2 What Do I Need To Know
- JSON B & JSON P - in the session named: What’s Next For JAX-RS 2.1
- Another session on JSON P - in the session named: What’s New In The Java API For JSON Processing
#14YearsOfAgile-TheGoodTheBayAndTheUgly......
A Birds of Feather (BOF) session, an informal session, meaning no one was presenting but rather a discussion and story telling kind of a hangout. Everyone reflected on their Agile practices over the years and shared personal experiences, off-course the good, the bad and the ugly.
A Birds of Feather (BOF) session, an informal session, meaning no one was presenting but rather a discussion and story telling kind of a hangout. Everyone reflected on their Agile practices over the years and shared personal experiences, off-course the good, the bad and the ugly.
No comments:
Post a Comment