Java 8: Base64 encoding and decoding

Java 8 has come up with inbuilt encoder and decoder for Base64 encoding. Base 64 class is present in java.util package.

This class consists exclusively of static methods for obtaining encoders and decoders for the Base64 encoding scheme. The implementation of this class supports the following types of Base64 encodings:

• Basic

The encoder does not add any line feed (line separator) character and the output is mapped to characters in the Base64 Alphabet: A-Za-z0-9+/. The decoder rejects data that contains characters outside the Base64 alphabet.

Read More

Java 8: Interface Static methods

Static methods are introduced in Java 8, just like default methods. If you don't know about interface default methods, read it first here.

Static methods are similar to default methods except that they cannot be overridden in their implementing classes. 
Let’s take an example:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

public class StaticInterfaceExample implements MyInterface { public static void main(String args[]) { StaticInterfaceExample obj = new StaticInterfaceExample(); obj.getTrimmedString(" Java Territory "); obj.isNullOrEmpty("Java Territory"); } public boolean isNullOrEmpty(final String str) { System.out.println("Interface Null Check"); return str.isEmpty(); } } interface MyInterface { static boolean isNullOrEmpty(final String string) { System.out.println("Inside isNullOrEmpty MyInterface"); return (string == null || string.isEmpty()) ? true : false; } default String getTrimmedString(String string) { String trimmedText = null; if (!isNullOrEmpty(string)) { System.out.println("Inside getTrimmedString MyInterface"); trimmedText = string.trim(); } return trimmedText; } }

Their are two implementations of isNullOrEmpty method, one in interface and one in implementing class.

What output do we get on executing above code? It's:

Inside isNullOrEmpty MyInterface Inside getTrimmedString MyInterface Inside isNullOrEmpty StaticInterfaceExample

Its important to note here that isNullOrEmpty(final String string) is not overriding the interface method. Compiler error  would be generated if we add @Override annotation to the isNullOrEmpty(final String string) method in StaticInterfaceExample.

If we make the interface method from static to default, we will get following output.

Inside isNullOrEmpty StaticInterfaceExample Inside getTrimmedString MyInterface Inside isNullOrEmpty StaticInterfaceExample

The static methods are visible to interface methods only, if we remove the isNullOrEmpty method from the StaticInterfaceExample class, we won’t be able to use it for the StaticInterfaceExample object. 

However like other static methods, we can use interface static methods using class name. For example, a valid statement will be:
boolean isNullOrEmpty = MyInterface.isNullOrEmpty ("abc");

Points to remember:

1. Interface static methods are visible within interface only, they can't be used by implementation class objects.
2. They can be used for utility methods.
3. They secure the application by not allowing implementation classes to override them.
4. They cant be overridden by implementing classes. Compile time error would get generated if any one try to do so.

Hope you liked the post. Join at +Java Territory to stay updated with latest articles.

Read More

Java 8 | New Date and Time library

Why do we need a new date and time library?

A long-standing bugbear of Java developers has been the inadequate support for the date and time use cases of ordinary developers. For example, the existing classes (such as java.util.Date and SimpleDateFormatter) aren’t thread-safe, leading to potential concurrency issues for users—not something the average developer would expect to deal with when writing date-handling code. Some of the date and time classes also exhibit quite poor API design. For example, years in java.util.Date start at 1900, months start at 1, and days start at 0—not very intuitive.

These issues, and several others, have led to the popularity of third-party date and time libraries, such as Joda-Time. In order to address these problems and provide better support in the JDK core, a new date and time API, which is free of these problems, has been designed for Java SE 8.

The project has been led jointly by the author of Joda-Time (Stephen Colebourne) and Oracle, under JSR 310, and will appear in the new Java SE 8 package java.time.

Core Ideas

The new API is driven by three core ideas: 

·         Immutable-value classes. One of the serious weaknesses of the existing formatters in Java is that they aren’t thread-safe. This puts the burden on developers to use them in a thread-safe manner and to think about concurrency problems in their day-to-day development of date-handling code. The new API avoids this issue by ensuring that all its core classes are immutable and represent well-defined values.

·         Domain-driven design. The new API models its domain very precisely with classes that represent different use cases for Date andTime closely. This differs from previous Java libraries that were quite poor in that regard. For example, java.util.Daterepresents an instant on the timeline—a wrapper around the number of milli-seconds since the UNIX epoch—but if you calltoString(), the result suggests that it has a time zone, causing confusion among developers.

This emphasis on domain-driven design offers long-term benefits around clarity and understandability, but you might need to think through your application’s domain model of dates when porting from previous APIs to Java SE 8.

·         Separation of chronologies. The new API allows people to work with different calendaring systems in order to support the needs of users in some areas of the world, such as Japan or Thailand, that don’t necessarily follow ISO-8601. It does so without imposing additional burden on the majority of developers, who need to work only with the standard chronology.

LocalDate and LocalTime

The first classes you will probably encounter when using the new API are LocalDate and LocalTime. They are local in the sense that they represent date and time from the context of the observer, such as a calendar on a desk or a clock on your wall. There is also a composite class called LocalDateTime, which is a pairing of LocalDate and LocalTime.

The existing classes aren’t thread-safe, leading to potential concurrency issues for users—not something the average developer would expect.

Time zones, which disambiguate the contexts of different observers, are put to one side here; you should use these local classes when you don’t need that context. A desktop JavaFX application might be one of those times. These classes can even be used for representing time on a distributed system that has consistent time zones.

Creating Objects

All the core classes in the new API are constructed by fluent factory methods. When constructing a value by its constituent fields, the factory is called of; when converting from another type, the factory is called from. There are also parse methods that take strings as parameters. See Listing 1. 

Paste your text here.LocalDateTime timePoint = LocalDateTime.now(); // The current date and time

LocalDate.of(2012, Month.DECEMBER, 12); // from values

LocalDate.ofEpochDay(150);  // middle of 1970

LocalTime.parse("10:15:30"); // From a String

LocalTime.of(17, 18); // the train I took home today

Listing 1 

Standard Java getter conventions are used in order to obtain values from Java SE 8 classes, as shown in Listing 2. 

LocalDate theDate = timePoint.toLocalDate();

Month month = timePoint.getMonth();

timePoint.getSecond();

int day = timePoint.getDayOfMonth();

Listing 2 

You can also alter the object values in order to perform calculations. Because all core classes are immutable in the new API, these methods are called with and return new objects, rather than using setters (see Listing 3). There are also methods for calculations based on the different fields. 

// Set the value, returning a new object

LocalDateTime thePast = timePoint.withDayOfMonth(10).withYear(2010);

or pass a value and field pair */

/* You can use direct manipulation methods,

LocalDateTime yetAnother = thePast.plusWeeks(3).plus(3, ChronoUnit.WEEKS);

Listing 3 

The new API also has the concept of an adjuster—a block of code that can be used to wrap up common processing logic. You can either write a WithAdjuster, which is used to set one or more fields, or a PlusAdjuster, which is used to add or subtract some fields. Value classes can also act as adjusters, in which case they update the values of the fields they represent. Built-in adjusters are defined by the new API, but you can write your own adjusters if you have specific business logic that you wish to reuse. See Listing 4. 

import static java.time.temporal.TemporalAdjusters.*;

LocalDateTime timePoint = ...

bar = timePoint.with(previousOrSame(ChronoUnit.WEDNESDAY));

foo = timePoint.with(lastDayOfMonth());

timePoint.with(LocalTime.now()); 

// Using value classes as adjusters

Listing 4 

Truncation

The new API supports different precision time points by offering types to represent a date, a time, and date with time, but obviously there are notions of precision that are more fine-grained than this.

The truncatedTo method exists to support such use cases, and it allows you to truncate a value to a field, as shown in Listing 5. 

LocalTime truncatedTime = time.truncatedTo(ChronoUnit.SECONDS);

Listing 5 

Time Zones

The local classes that we looked at previously abstract away the complexity introduced by time zones. A time zone is a set of rules, corresponding to a region in which the standard time is the same. There are about 40 of them. Time zones are defined by their offset from Coordinated Universal Time (UTC). They move roughly in sync, but by a specified difference.

Time zones can be referred to by two identifiers: abbreviated, for example, “PLT,” and longer, for example, “Asia/Karachi.” When designing your application, you should consider what scenarios are appropriate for using time zones and when offsets are appropriate. 

·         ZoneId is an identifier for a region (see Listing 6). Each ZoneId corresponds to some rules that define the time zone for that location. When designing your software, if you consider throwing around a string such as “PLT” or “Asia/Karachi,” you should use this domain class instead. An example use case would be storing users’ preferences for their time zone.

// You can specify the zone id when creating a zoned date time

ZoneId id = ZoneId.of("Europe/Paris");

assertEquals(id, ZoneId.from(zoned));

ZonedDateTime zoned = ZonedDateTime.of(dateTime, id);

Listing 6

·         ZoneOffset is the period of time representing a difference between Greenwich/UTC and a time zone. This can be resolved for a specific ZoneId at a specific moment in time, as shown in Listing 7.  

ZoneOffset offset = ZoneOffset.of("+2:00");

Listing 7

Time Zone Classes 

ZonedDateTime is a date and time with a fully qualified time zone (see Listing 8). This can resolve an offset at any point in time. The rule of thumb is that if you want to represent a date and time without relying on the context of a specific server, you should useZonedDateTime.  

ZonedDateTime.parse("2007-12-03T10:15:30+01:00[Europe/Paris]");

Listing 8

·         OffsetDateTime is a date and time with a resolved offset. This is useful for serializing data into a database and also should be used as the serialization format for logging time stamps if you have servers in different time zones.

·         OffsetTime is a time with a resolved offset, as shown in Listing 9. 

OffsetTime time = OffsetTime.now(); // changes offset, while keeping the same point on the timeline

OffsetTime sameTimeDifferentOffset = time.withOffsetSameInstant(offset);

OffsetTime changeTimeWithNewOffset = time.withOffsetSameLocal(offset);// changes the offset, and updates the point on the timeline

changeTimeWithNewOffset.withHour(3).plusSeconds(2);

// Can also create new object with altered fields as before

Listing 9

There is an existing time zone class in Java—java.util.TimeZone—but it isn’t used by Java SE 8 be-cause all JSR 310 classes are immutable and time zone is mutable.

Periods

A Period represents a value such as “3 months and 1 day,” which is a distance on the timeline. This is in contrast to the other classes we’ve looked at so far, which have been points on the timeline. See Listing 10. 

// 3 years, 2 months, 1 day

Period period = Period.of(3, 2, 1);

// You can modify the values of dates using periods

LocalDate newDate = oldDate.plus(period);

ZonedDateTime newDateTime = oldDateTime.minus(period);

// Components of a Period are represented by ChronoUnit values

assertEquals(1, period.get(ChronoUnit.DAYS)); 

Listing 10

Java SE 8 will ship with a new date and time API in java.time that offers greatly improved safety and functionality for developers. The new API models the domain well, with a good selection of classes for modeling a wide variety of developer use cases.

Durations

A Duration is a distance on the timeline measured in terms of time, and it fulfills a similar purpose to Period, but with different precision, as shown in Listing 11. 

// A duration of 3 seconds and 5 nanoseconds

Duration duration = Duration.ofSeconds(3, 5);

Duration oneDay = Duration.between(today, yesterday);

Listing 11 

It’s possible to perform normal plus, minus, and “with” operations on a Durationinstance and also to modify the value of a date or time using the Duration.

Chronologies

In order to support the needs of developers using non-ISO calendaring systems, Java SE 8 introduces the concept of a Chronology, which represents a calendaring system and acts as a factory for time points within the calendaring system. There are also interfaces that correspond to core time point classes, but are parameterized by

Chronology:

ChronoLocalDate

ChronoLocalDateTime

ChronoZonedDateTime

These classes are there purely for developers who are working on highly internationalized applications that need to take into account local calendaring systems, and they shouldn’t be used by developers without these requirements. Some calendaring systems don’t even have a concept of a month or a week and calculations would need to be performed via the very generic field API.

Java SE 8 also has classes for some other common use cases. There is the MonthDay class, which contains a pair of Month and Day and is useful for representing birthdays. The YearMonth class covers the credit card start date and expiration date use cases and scenarios in which people have a date with no specified day.The Rest of the API

JDBC in Java SE 8 will support these new types, but there will be no public JDBC API changes. The existing generic setObject andgetObject methods will be sufficient.

These types can be mapped to vendor-specific database types or ANSI SQL types; for example, the ANSI mapping looks like Table 1.

ANSI SQL	Java SE 8
DATE	LocalDate
TIME	LocalTime
TIMESTAMP	LocalDateTime
TIME WITH TIMEZONE	OffsetTime
TIMESTAMP WITH TIMEZONE	OffsetDateTime

Table 1

Conclusion

Java SE 8 will ship with a new date and time API in java.time that offers greatly improved safety and functionality for developers. The new API models the domain well, with a good selection of classes for modeling a wide variety of developer use cases.

Reference: http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

Read More

Java 8 | StringJoiner

Java 8 has introduced a new String manipulation API StringJoiner, using which one can append multiple string values within the pre-defined format like commas, prefix and suffix.

public final class StringJoiner extends Object

StringJoiner is used to construct a sequence of characters separated by a delimiter and optionally starting with a supplied prefix and ending with a supplied suffix.

Constructor and Description

StringJoiner(CharSequence delimiter) Constructs a StringJoiner with the supplied infix delimiter.

StringJoiner(CharSequence delimiter, CharSequence prefix, CharSequence suffix) Constructs a StringJoiner using copies of the supplied prefix, delimiter and suffix.

For example:

To construct the following String using StringJoiner separated by an infix delimiter and starting with a prefix and ending with a suffix:

[John:Katy:Fred] 

StringJoiner sj = new StringJoiner( ":", "[", "]" );

sj.add( "John" ).add( "Katy" ).add( "Fred" );

String desiredString = sj.toString();

Method and Description

StringJoiner add(CharSequence newElement) Adds new string into the StringJoiner object.

int length() Returns the length of the String representation of the StringJoiner object.

StringJoiner setEmptyValue(CharSequence emptyValue) Sets the sequence of characters to be used when the string representation of the StringJoiner is empty.

String toString() Returns the String representation.

It can particularly be useful when creating a formatted output from a Stream using Collectors.joining(CharSequence). For example:

 List<Integer> numbers = Arrays.asList(1, 2, 3, 4);

 String commaSeparatedNumbers = numbers.stream()

.map(i -> i.toString())

.collect(Collectors.joining(", "));

That’s OK if you are not familiar with Lambda expressions, used in example above. Will cover the same in coming tutorials. Subscribe at +Java Territory to stay updated.

Read More

Java 8 New Feature: String Deduplication

String objects consume a large amount of memory even in a small application. Various enhancements has been made relating to String in Java. Java 7 Update 6 improved the speed of String.substring() by sacrificing a little memory efficiency. Java 8 Update 20 takes a different approach by sacrificing a little CPU efficiency in order to reduce memory footprint. On the long run this should reduce the strain on the CPU too. In other words, most real world programs should run faster.

Java programs create huge quantity of character arrays. Most of them are part of String objects, meaning there’s a pointer to a character array. In practice, a lot of Strings are duplicated conduming huge amount of heap space.

Read More

JAVA 8: Default methods in an interface

Normal interface methods are declared as abstract and must be defined in the class that implements the interface. This 'burdens' the class implementer with the responsibility to implement every declared method. More importantly, this also means that extending an interface is not possible after 'publication'. Otherwise, all implementers would have to adapt their implementation, breaking backwards source and binary compatibility.

To cope with these problems, one of the new features of JDK 8 is the possibility to extend existing interfaces with default methods. Default methods are not only declared, but also defined in the interface. Here is an example:

 public interface Person {  
  public abstract String getFirstName();  
  public abstract String getLastName();  
  public default String getDisplayableFullName() {  
   return getLastName() + ", " + getFirstName();  
  }  
  public abstract boolean isStudent();  
  public default boolean isNotStudent() {  
   return !isStudent();  
  }  
 }  

Implementers of the Person interface need to define getFirstName(), getLastName(), and isStudent(). But they can choose not to implement getDisplayableFullName(), or isNotStudent(). Implementers can still override default methods, like regular non-final class methods can be overridden in subclasses. Abstract classes can even (re)declare default methods as abstract, forcing subclasses to reimplement the method (sometimes called 're-abstraction').

Use cases for default methods

Extending existing interfaces

The most important use case for this new feature in the JDK libraries is the possibility to extend existing interfaces without breaking existing implementers: adding a new abstract method to an interface would require all implementing classes to implement that new method. And extending existing interfaces was necessary to allow for the backwards-compatible implementation of the new Stream API that will extend the Collections API (see my third blog post on JDK 8). A snippet from the new Collection interface:

 public interface Collection<E> extends Iterable<E> {  
  // Traditional, abstract methods:  
  int size();  
  boolean contains(Object o);  
  boolean add(E e);  
  boolean remove(Object o);  
  // Etc...  
  // New methods stream() and parallelStream() with default implementations:  
  default Stream<E> stream() {  
   return Streams.stream(() -> Streams.spliterator(iterator(), size(), Spliterator.SIZED), Spliterator.SIZED);  
  }  
  default Stream<E> parallelStream() {  
   return stream().parallel();  
  }  
 }  

The Collection interface is extended with the stream() and parallelStream() methods. Each must be defined as default method, otherwise existing Collection implementers (such as ArrayList, or from third parties) would break, or would have to implement those methods.

Additional design flexibility in the inheritance hierarchy

Sometimes functionality can be shared between different implementing classes. Traditionally, this was done by creating an (abstract) superclass for the different classes. In other cases, such as when defining a listener for an event, an interface with multiple methods must be implemented, but the implementer is only interested in implementing a single event, i.e., a single method. Usually an abstract (adapter) class is extended to provide default implementations for these interface methods.
In both situations, default method implementations can provide more design flexibility. Similar to traits in Scala, default methods enable the sharing or reuse of behavior between different types. And because a class can implement multiple interfaces, a safe and limited form of multiple inheritance is supported. To share state, an (abstract) superclass is still required.

Alternative: extension methods

As an alternative, a variant of C# extension methods was considered. However, extension methods introduce new 'static-ness': they are static methods that take as their first argument the object on which they operate. They are basically syntactic sugar: the construct allows the programmer to 'dot into' the extension method in an IDE.
One of the problems with this approach is that implementers could not override the method, and the entire class hierarchy would be stuck with a one-size-fits-all implementation. In general, introducing additional static methods on a large scale in this manner was considered undesirable. Also, extension methods would not behave nicely when using reflection: the extension methods would not be discoverable, as they would not be part of the declared methods of a class (consider the situation in which the mail class is loaded, inspected through reflection, and only then the class with extension methods is loaded - the JVM would never know about the extension methods).

Static methods can also be written in interfaces in Java 8. Read more about interface static methods here.
You can also follow us at +Java Territory to stay updated with latest articles.

Read More