Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Sunday, March 30, 2014

The Illuminating Javadoc of JDK 8

One of the nice features of the standard JDK 8 API documentation is the ability to view all or different categories of methods as discussed in my blog post JDK 8 Javadoc Tweaked For Methods Listings. As convenient and useful as this categorization is, the text comments associated with many of the new classes and packages in JDK 8 are arguably even more useful, especially as many of us start to adopt JDK 8. I look at some of examples of highly useful JDK 8 API documentation in this post. In the course of this quick perusal of the JDK 8 Javadoc documentation, anyone entirely new to JDK 8 is bound to learn something about the libraries of JDK 8.

Good examples of the usefulness of the JDK 8 API documentation are in the familiar String class documentation. That class features two new overloaded static methods, join(CharSequence, CharSequence…) and join(CharSequence delimiter, Iterable elements). The Javadoc comments for these two new methods not only explain the methods’ behaviors, but illustrate them with code that demonstrates the methods in use. This is similar to the Javadoc comment I’ve always found helpful on the String.substring(int, int) method.

The all-new StringJoiner class includes code examples of its usage in the class-level Javadoc comments. One of the code examples seems targeted toward easing “traditional Java development” while the second example applies the power of lambda expressions and streams.

Code examples are used liberally in other new (to JDK 8) classes’ Javadoc documentation as well, especially in the java.util.streams package. The class-level Javadoc documentation for the java.util.stream.Collectors class provides code examples of 7 potential uses for Collectors such as accumulation and grouping. The Stream interface provides an example of useful JDK 8 documentation on an interface. The text detail on applying the Stream interface is accompanied by a simple code example that demonstrates “an aggregate operation using Stream and IntStream.” The java.util.stream package itself has great description text regarding Streams that includes a simple example of employing a Stream with a detailed discussion of what is going on with that example. The package documentation for java.util.stream goes onto discuss several different aspects of using Streams such as stream operations and pipelines, parallelism, side effects, and reduction.

Just as it is important to understand Streams when working with JDK 8 lambda expressions, it is also useful to understand functional interfaces when using lambda expressions and the java.util.function package-level description provides a nice overview.

Another good example of JDK 8 Javadoc-based documentation with enlightening code examples is the documentation for Calendar.Builder, a class I covered in the post JDK 8′s Calendar.Builder.

Most of the JDK 8 Javadoc-based documentation I’ve discussed so far provides code examples demonstrating use of the described package, class, or interface. Some of the new JDK API documentation uses code to demonstrate the new API feature by showing code that formerly would have needed to be written but is replaced by the new feature. Good examples of this exist in the well-known Java Map interface. The Java Map interface has several new methods specified in JDK 8 and many of these new JDK 8 methods include Javadoc documentation indicating code that would have been required prior to JDK 8 to accomplish the same thing as the newly added method. For example, the methods computeIfAbsent, computeIfPresent, forEach, getOrDefault, and putIfAbsent methods all have comments providing code demonstrating what the “default implementation is equivalent to.” Although this may be explaining the default behavior of Map implementations, it is also useful for understanding the type of pre-JDK 8 code these methods emulate or replace.

JDK 8 introduces a completely new Date/Time API and the java.time package has a nice package-level overview of the API. Constructs in this entirely new package have individual level comments that are useful for learning this API. Examples include Clock, Instant, LocalDateTime, Period, and ZonedDateTime. The package-level documentation helps clarify the relationship between LocalDate, LocalDateTime, LocalTime, ZonedDateTime, and Instant.

JDK 8 Javadoc isn’t only changed for the standard JDK API. JDK 8 brings some enhancements to the javadoc tool that will impact developers’ own Javadoc comments and code. It is also important to be aware of the -Xdoclint:none option (mentioned in Stephen Colebourne’s blog post Turning off doclint in JDK 8 Javadoc) for preventing Javadoc that doesn’t conform to “W3C HTML 4.01 HTML” from breaking. The final bullet on the Enhancements in Javadoc, Java SE 8 page states that this Javadoc HTML conformance compliance “feature is also available in javac, although it is not enabled by default there.” That same bullet tells us that we can learn more about the -Xdoclint:none flag by running javadoc -X.

Conclusion

I sometimes hear that there is never a need for comments when the code speaks for itself. I believe that is true to a degree, but the presence of useful Javadoc comments on packages, classes, and interfaces and their methods that were introduced with JDK 8 will make the adoption of JDK 8 much quicker than reading everyone of these constructs’ code listings would. It reinforces my opinion that we often don’t need comments on specific lines of code that do something, but most often do need comments on interfaces and contracts. In my ideal world, the code would be so well written that the only necessary comments would be Javadoc style comments (/** */) and we’d need very little // or /* */ style comments. JDK 8 continues a trend that has occurred in recent major revisions of the JDK of improved Javadoc comments in terms of readability and understandability.

Wednesday, March 26, 2014

How to use NodeManager to control WebLogic Servers

One downside with that instruction is that those processes will start in foreground and the STDOUT are printed on terminal. If you intended to run these severs as background services, you might want to try the WebLogic node manager wlscontrol.sh tool. I will show you how you can get Node Manager started here.

The easiest way is still to create the domain directory with the admin server running temporary and then create all your servers through the /console application as described in last post. Once you have these created, then you may shut down all these processes and start it with Node Manager.

1cd $WL_HOME/server/bin && startNodeManager.sh &
2$WL_HOME/common/bin/wlscontrol.sh -d mydomain -r $HOME/domains/mydomain -c -f startWebLogic.sh -s myserver START
3$WL_HOME/common/bin/wlscontrol.sh -d mydomain -r $HOME/domains/mydomain -c -f startManagedWebLogic.sh -s appserver1 START

The first step above is to start and run your Node Manager. It is recommended you run this as full daemon service so even OS reboot can restart itself. But for this demo purpose, you can just run it and send to background. Using the Node Manager we can then start the admin in step 2, and then to start the managed server on step 3.

The NodeManager can start not only just the WebLogic server for you, but it can also monitor them and automatically restart them if they were terminated for any reasons. If you want to shutdown the server manually, you may use this command using Node Manager as well:

The first step above is to start and run your Node Manager. It is recommended you run this as full daemon service so even OS reboot can restart itself. But for this demo purpose, you can just run it and send to background. Using the Node Manager we can then start the admin in step 2, and then to start the managed server on step 3.

The NodeManager can start not only just the WebLogic server for you, but it can also monitor them and automatically restart them if they were terminated for any reasons. If you want to shutdown the server manually, you may use this command using Node Manager as well:

1$WL_HOME/common/bin/wlscontrol.sh -d mydomain -s appserver1 KILL

The Node Manager can also be used to start servers remotely through SSH on multiple machines. Using this tool effectively can help managing your servers across your network. You may read more details here: http://docs.oracle.com/cd/E23943_01/web.1111/e13740/toc.htm

TIPS1: If there is problem when starting server, you may wnat to look into the log files. One log file is the <domain>/servers/<server>/logs/<server>.out of the server you trying to start. Or you can look into the Node Manager log itself at $WL_HOME/common/nodemanager/nodemanager.log

TIPS2:
You add startup JVM arguments to each server starting with Node Manager. You need to create a file under <domain>/servers/<server>/data/nodemanager/startup.properties and add this key value pair: Arguments = -Dmyapp=/foo/bar

TIPS3: If you want to explore Windows version of NodeManager, you may want to start NodeManager without native library to save yourself some trouble. Try adding NativeVersionEnabled=false to $WL_HOME/common/nodemanager/nodemanager.properties
file.

Tuesday, March 18, 2014

Java EE 8 : What does the community want?

Following the earlier two community surveys, the first announced in December 2013 and the second in January 2014, Oracle calls the enterprise community for a third and final survey on Java EE 8.  The closing date for the survey will be March 24, 2014 at 12 AM Pacific Time.


It is worth noting that while the first two surveys revealed the specific features that Java EE community requested most for the new upgraded 8 version, this third one will focus on imposing a priority order upon them.

It is a given that it’s impossible for all of the requested features to make it to the final release, and it is certainly sure that Java EE 8 creators have a very specific set of features to add that are not met in the results of these surveys. That’s why they asked the community basically to choose the most important/wanted ones.

Some early results of the survey reveal the most anticipated features :
  • 79% requested the inclusion of  JSR for Java API for JSON Binding
  • 77% requested a standard Java API for server-side events
  • 79% requested security enhancements, including interceptors
  • 77% chose RESTful Deployment, Management, and Monitoring APIs, over JMX or others.
  • 40% denoted that is too early to concur with on NoSQL standards, despite the maturity and the acceptance of the technology for the industry
It is natural that the final results of that survey will play a crucial role on Oracle’s decisions about the new features of Java EE 8.