Simplifying the cloud native journey with GraalVM and Helidon

Simplifying the Cloud Native journey with GraalVM Enterprise and Helidon

Standard Chartered Bank, an international banking and financial services company with 1026 branches across the globe and 86,000 employees, set out to build fast and efficient cloud native Java applications. For maximum performance and productivity they chose GraalVM and Helidon.

To build stable and robust banking solutions, Standard Chartered’s development teams use mostly Java, along with some Python and other languages with the Spring Boot framework, JAX and other tools. For external developers, they offer an advanced API and aXess – Open Banking platform, that allows developers and partners to create banking products. Standard Chartered has also recently launched a virtual bank called Mox, built on a modern next generation devops platform.

While working on a new project, the Internet Banking team within Standard Chartered was looking for a way to make their Java applications start fast, be ready for cloud deployment, and also streamline their CI/CD pipeline.

SCB’s Cloud Strategy, accelerated by Oracle

Standard Chartered Bank’s cloud strategy was kick started in 2016 with enhanced focus on Private Cloud using OpenShift Container Platform in their own premises. While SCB always had experienced technical teams proficient in Java, the migration from traditional JBoss deployments to Kubernetes had its own set of challenges. Partnering with Oracle and adopting the newest Java features for a container-first architecture has greatly facilitated the migration to Kubernetes. SCB is a major user of JDK, Oracle Database, and of course their flagship product – Oracle WebLogic. These products power mission critical applications inside the Bank and server more than 40 markets across the planet.

Standard Chartered's partnership with Oracle strengthened even more, thanks to the migration to Public Cloud. Cloud migration strategies paved the way to focus on open source software, and writing efficient, secure, and instantly scalable microservices. Decades of JavaEE expertise has paved the way to finding Helidon as the faster, leaner, and modern younger sibling to WebLogic. Out of the box support for common authentication mechanisms such as OIDC, OAuth etc. support for tracing mechanisms like Prometheus, Zipkin just reaffirmed their choice.

Research and Evaluation

To improve the performance of applications and make them cloud native, the team considered a few options, such as rewriting their apps in Go, migrating to Kotlin and using a custom jlink-generated JRE, or using GraalVM Enterprise as runtime.

One important consideration when evaluating prototypes is how well they fit into cloud deployment scenarios. The ideal solution would allow applications to start fast and use as little memory as possible, since compute and memory resources affect cloud costs, and this becomes even more important at scale with high-load banking systems. 

Another aspect of evaluation is scalability. One of the primary reasons to move to cloud is to take advantage of their ability to scale up and down quickly to meet demand, or roll out new updates fast, but that becomes a challenge when facing traditional VM cold starts.

Another key focus for Standard Chartered was to determine if Java would support their move to cloud or whether they would have to migrate to another language. Java was their preferred choice because of the team’s expertise in the language combined with Java’s rich ecosystem, strong community, and advanced tools.

As the team discovered, GraalVM Native Image technology offered a solution for all those challenges. The applications could be still written in Java and compiled into native executables, which have reduced startup times up to 50x faster compared to running in JVM mode since the code is optimized in advance. Native executables also use ~5x less memory since they don’t require a JVM or a JIT compiler and the memory overhead incurred by its code code caches and performance profile data. 

A native executable includes all necessary runtime libraries so it can be put into a `FROM scratch` container. For a basic microservice, the container size can be as low as 20-25 MBs.

GraalVM’s ability to produce native executables for Java applications is widely recognized by popular Java frameworks with Micronaut, Helidon and Quarkus already include GraalVM Native Image integration. The Spring Boot team is also actively working on an integration project. In practice, well known cloud-scale companies like Alibaba have reported that native executables generated by GraalVM Native Image provide excellent performance under extreme load.

Evaluation results

Along with GraalVM Enterprise, the Standard Chartered team evaluated Helidon, which provides an open source, lightweight, cloud native framework for developing Java microservices. It comes in two versions: Helidon SE is designed to be a microframework that supports the reactive programming model, while Helidon MP supports the execution of portable microservices that comply with the Eclipse MicroProfile specification. The team decided to try Helidon SE, since support for reactive services and lightweight applications were a better fit for the project goals.

To evaluate GraalVM and Helidon, the team ran a sample app and measured startup time and Docker image size. The app was a typical enterprise application with connectors to Kafka and ActiveMQ along with Hibernate to access a PostgreSQL database. Benchmark environment: AMD Ryzen 7 3700x (8-core with hyperthreading), Linux kernel 5.9.16 Fedora.

Startup characteristics of GraalVM Native Image vs other runtimes

Docker image size of GraalVM Native Image vs other runtimes

The team observed that when benchmarked on the same JDK version, GraalVM offers up to 7% reduction in startup time, and the native image reduces startup time by 90%. Recent versions of OpenJDK have improved JVM startup time, and this assures that the future versions of GraalVM based on OpenJDK 17 LTS will offer similar benefits. It’s also observed that GraalVM Enterprise offers up to 15% improved memory usage in high throughput scenarios, over GraalVM Community.

Source: oracle.com

Continue reading

GraalVM Enterprise 21.2—Productivity and Performance

The latest GraalVM Enterprise 21.2 release delivers both new performance features, and improved developer experience—including enhancements to GraalVM Native Image to make it easier than ever to compile applications into native executables.

Let’s take a look at some of the highlights of the GraalVM Enterprise 21.2 release, available as part of an Oracle Java SE Subscription.

Relentless Focus on Performance

With new compiler optimizations in 21.2, GraalVM Enterprise continues to improve application performance for many workloads. As it is based on Oracle JDK these benefits can be enjoyed without requiring code changes.

GraalVM 21.2 also includes new developer tool features and capabilities, and enhancements to the GraalVM Native Image feature that make it easier than ever to compile applications into native executables. At the heart of GraalVM is the advanced optimizing Graal compiler which provides just-in-time (JIT) compilation for applications running on the Oracle JDK HotSpot JVM, and ahead-of-time (AOT) compilation in the Native Image utility which generates native executables. In both cases, the Graal compiler is responsible for turning high-level Java bytecodes into native machine instructions that can be run by a CPU, whether it be an Intel/AMD x86 or ARM Aarch64 processor.

Processor architectures and instruction sets continue to rapidly evolve bringing new capabilities that can, if used, accelerate application performance. “If used” is the key here. Java developers rely on the bytecode compiler to exploit the latest hardware features for them. If the compiler does not include optimizations for these new features, an application won’t benefit from them. For example, Intel’s AVX512 and ARM’s NEON architectures have expanded SIMD (Single Instruction Multiple Data) capabilities designed to accelerate “audio and video encoding and decoding, user interface, 2D/3D graphics, and gaming…signal processing…audio and video processing, voice and facial recognition, computer vision, and deep learning.” To take advantage of these SIMD instructions, the GraalVM Enterprise 21.2 compiler has added two new vectorization optimizations to its already substantial set (see "Java and Compiler Updates" in the release notes). Throughput on some microbenchmarks has improved by about 30%!

Developer Experience

GraalVM 21.2 includes many new development tool capabilities and a number of significant improvements to GraalVM Native Image.

GraalVM Native Image uses the Graal compiler to generate native machine code from Java bytecode at build time, instead of at runtime, and generates platform specific executables for Linux, Mac, and Windows. This approach creates applications that can start up to 100 times faster and consume significantly less memory and CPU than when running on a Java Virtual Machine (JVM). Not running on a JVM means GraalVM Native Image has to provide support for features JVMs provide, but in a context where all code is compiled ahead-of-time. GraalVM 21.2 adds novel support for Java class and resource loading APIs that developers use regularly. With this new support, applications using these APIs can be compiled unchanged to machine executables, making it much easier to migrate existing applications to GraalVM Native Image.

JDK Flight Recorder (JFR) is an important and popular monitoring feature making its first appearance in GraalVM 21.2 Native Image. JFR makes it possible to collect diagnostic and profiling data from a running Java application with minimal overhead. The GraalVM 21.2 release includes the core JFR infrastructure support required to gather and report metrics from executables generated by GraalVM Native Image. Monitoring for a wide range of metrics and events will be added in upcoming releases. The introduction of low overhead JFR profiling data generation in native executables is designed to make it easier to build, deploy, and monitor these applications in production environments where performance is critical and monitoring is absolutely necessary. 

GraalVM 21.2 also includes JFR tooling enhancements. Once you've generated JFR diagnostic and profiling data, the next step is analysis and the premier tool for JFR analysis is VisualVM. VisualVM has had JFR support for a few years, but the GraalVM 21.2 release adds support for configuring which specific metrics to capture, as well as controls to start, stop, and dump data from an application running on the HotSpot JVM. Similar support for GraalVM Native Image generated executables is expected in a future release.

Source: oracle.com

Continue reading

GraalVM Enterprise accelerates Java performance on Oracle Cloud Ampere A1

Oracle Cloud Infrastructure (OCI) is the best platform for Java cloud deployments offering highly competitive pricing and no-cost inclusion of GraalVM Enterprise to accelerate Java application performance. With the launch of OCI’s new Oracle Ampere A1 Compute platform, OCI has the best price-performance Java platform in the cloud with the high performance/low cost Ampere Altra processor and the new Altra-optimized GraalVM Enterprise JDK release.

GraalVM Enterprise—Faster. Smarter. Leaner.

Built on proven Oracle JDK, the GraalVM Enterprise JDK provides an easy way for Java developers to improve their application performance. GraalVM Enterprise’s advanced optimizing compiler produces faster code, reduces memory requirements, and cuts garbage collection time so that applications run faster and leaner.

The result of a decade of research and development in Oracle Labs, GraalVM Enterprise includes many unique and innovative compiler optimizations that make it possible for applications to run as much as 50% faster. With GraalVM Enterprise, any application implemented in Java, or in a JVM-language like Scala or Kotlin, should experience a performance boost—without changing a single line of code.

GraalVM Enterprise also includes a unique “Native Image” Ahead-of-Time compiler that generates native executables that start almost instantaneously and have very low memory requirements, making them ideal for microservices and other containerized workloads. With support from popular frameworks including Spring, Micronaut, Quarkus, and Helidon, GraalVM Native Image is the best solution for cloud native Java applications.

Benchmarking Java on Oracle Ampere A1

To illustrate the performance benefits of GraalVM Enterprise on OCI, we ran the Renaissance JVM benchmark suite on similarly configured Ampere A1 (Altra) Aarch64 and high-performance OCI X9-2 (Intel® Xeon® Gold 6354, “Ice Lake”) x86 instances with both OpenJDK 11 and GraalVM Enterprise and measured the time it took to run the full suite. The chart below shows the suite execution time geomean results for each configuration (lower is better). 

As we can see, GraalVM Enterprise is the fastest way to run Java applications on both platforms, making it the best choice for Java deployments on OCI regardless of the processor architecture choice. On average, GraalVM Enterprise is approximately 1.6x faster on the x86 platform and 1.5x faster on the Ampere A1 than OpenJDK. What may be surprising is that with GraalVM Enterprise the general-purpose Ampere A1 outperforms the HPC-oriented X9 with OpenJDK!

But this is just raw performance. Cost is the other factor we need to consider. The Ampere A1 offers extremely competitive pricing and the combination of GraalVM Enterprise and Ampere A1 may be the most cost-effective Java cloud deployment platform available!

Compute Costs

Let’s look at the costs for our test machines. Our benchmarks were run on X9 and Ampere A1 machines with 8 GB of RAM and 18 and 36 cores, respectively. The X9’s Xeon processors have two hardware threads while an Ampere Altra processor has one, so we doubled the number of Ampere A1 processors to ensure both machines had the same number of hardware threads available. Here’s the monthly cost for each configuration:

GraalVM Enterprise on Oracle Ampere A1—faster and cheaper

The monthly cost for our Ampere A1 test machine is around 60% less expensive than our X9! That’s a huge price difference but remember from the first performance chart that our Ampere A1 machine with GraalVM Enterprise also outperformed the X9 with OpenJDK 11. Let’s consider how the improved performance GraalVM Enterprise provides affects the cost of running a Java workload on OCI.

We’ve seen that GraalVM Enterprise significantly improves Java application throughput and we’ve also seen that the cost of an Ampere A1 machine is a fraction of the cost of a similarly configured X9. But what does this mean in practice?

Let’s consider a scenario where we have several batch workloads that take a full month to run on our X9 with OpenJDK. From the table above, we can see that this will cost $732.10 for the X9. But what will it cost to run these same workloads on our comparable Ampere A1 machine with GraalVM Enterprise? From our benchmark results, we can see that applications on Ampere A1 with GraalVM Enterprise run applications about 12% faster than on X9 with OpenJDK, which means our 31 days of work could be done in only 27 days. By running our workloads faster, we further reduce our already low Ampere A1 machine cost to just $243.77. Running the exact same workload on GraalVM Enterprise and an Ampere A1 machine is a whopping 67% cheaper than OpenJDK on X9!

As we can see, GraalVM Enterprise is the fastest way to run Java applications on both platforms, making it the best choice for Java deployments on OCI regardless of the processor architecture choice. On average, GraalVM Enterprise is approximately 1.6x faster on the x86 platform and 1.5x faster on the Ampere A1 than OpenJDK. What may be surprising is that with GraalVM Enterprise the general-purpose Ampere A1 outperforms the HPC-oriented X9 with OpenJDK!

OCI’s new Ampere A1 Compute platform based on the Ampere Altra processor offers an unparalleled price-performance value proposition. In combination with GraalVM Enterprise, included at no additional charge, Java applications deployed to Ampere A1 will enjoy the best performance at the lowest price on any cloud platform.

Source: oracle.com

Continue reading

Character Stream Vs Byte Stream in Java

I/O Stream

A stream is a method to sequentially access a file. I/O Stream means an input source or output destination representing different types of sources e.g. disk files. The java.io package provides classes that allow you to convert between Unicode character streams and byte streams of non-Unicode text.

Stream – A sequence of data.

Input Stream: reads data from source.

Output Stream: writes data to destination.

Character Stream

In Java, characters are stored using Unicode conventions. Character stream automatically allows us to read/write data character by character. For example FileReader and FileWriter are character streams used to read from source and write to destination.

// Java Program illustrating that we can read a file in

// a human readable format using FileReader

import java.io.*; // Accessing FileReader, FileWriter, IOException

public class OJC

{

public static void main(String[] args) throws IOException

{

FileReader sourceStream = null;

try

{

sourceStream = new FileReader("test.txt");

// Reading sourcefile and writing content to

// target file character by character.

int temp;

while ((temp = sourceStream.read()) != -1)

System.out.println((char)temp);

}

finally

{

// Closing stream as no longer in use

if (sourceStream != null)

sourceStream.close();

}

}

}

Output:

Shows contents of file test.txt 

Byte Stream

Byte streams process data byte by byte (8 bits). For example FileInputStream is used to read from source and FileOutputStream to write to the destination.

// Java Program illustrating the Byte Stream to copy

// contents of one file to another file.

import java.io.*;

public class BStream

{

public static void main(String[] args) throws IOException

{

FileInputStream sourceStream = null;

FileOutputStream targetStream = null;

try

{

sourceStream = new FileInputStream("sorcefile.txt");

targetStream = new FileOutputStream ("targetfile.txt");

// Reading source file and writing content to target

// file byte by byte

int temp;

while ((temp = sourceStream.read()) != -1)

targetStream.write((byte)temp);

}

finally

{

if (sourceStream != null)

sourceStream.close();

if (targetStream != null)

targetStream.close();

}

}

}

When to use Character Stream over Byte Stream? 

◉ In Java, characters are stored using Unicode conventions. Character stream is useful when we want to process text files. These text files can be processed character by character. A character size is typically 16 bits.

When to use Byte Stream over Character Stream?

◉ Byte oriented reads byte by byte. A byte stream is suitable for processing raw data like binary files.

Notes:

◉ Names of character streams typically end with Reader/Writer and names of byte streams end with InputStream/OutputStream

◉ The streams used in example codes are unbuffered streams and less efficient. We typically use them with buffered readers/writers for efficiency. We will soon be discussing use BufferedReader/BufferedWriter (for character stream) and BufferedInputStream/BufferedOutputStream (for byte stream) classes.

◉ It is always recommended to close the stream if it is no longer in use. This ensures that the streams won’t be affected if any error occurs.

◉ The above codes may not run in online compilers as files may not exist.

Source: geeksforgeeks.org

Continue reading

Performance impact of java.lang.System.getProperty()

‘java.lang.System.getProperty()’ is a common API used by Java developers to read the System properties that are configured during application startup time. i.e. when you pass “-DappName=buggyApp” as your application’s startup JVM argument, the value of the ‘appName’ system property can be read by invoking the ‘java.lang.System.getProperty()’. Example:

public static String getAppName() {

   String app = System.getProperty("appName");

   return app;

}

When the above method is invoked, ‘buggyApp’ will be returned. However, if ‘java.lang.System.getProperty()’ is used in a critical code path, it has a potential to degrade the application’s performance. In this post let’s discuss what is the performance impact of invoking ‘java.lang.System.getProperty()’, how to mitigate it and a real-world production problem triggered by this API.

What is the performance impact of using ‘java.lang.System.getProperty()’ API?

 ‘java.lang.System.getProperty()’ API underlyingly uses ‘java.util.Hashtable.get()’ API. Please be advised that ‘java.util.Hashtable.get()’ is a synchronized API. It means only one thread can invoke the ‘java.util.Hashtable.get()’ method at any given time. If a new thread tries to invoke ‘java.util.Hashtable.get()’ API when the first thread is still executing it, the new thread will be put in a BLOCKED state. When a thread is in the BLOCKED state, it won’t be able to progress forward. Only when the first thread completes executing the ‘java.util.Hashtable.get()’ API, new thread will be able to progress forward. Thus if ‘java.lang.System.getProperty()’ or ‘java.util.Hashtable.get()’ is invoked in critical code paths, it will impact the response time of the transaction.

Real-world problem in Atlassian SDK

Recently this type of degradation was observed in Atlassian SDK. Thread dump was captured from this application and analyzed using the thread dump analysis tool – fastThread. 

According to the thread dump analysis report, 189 threads were in the BLOCKED state. Below is the transitive dependency graph from the thread dump report showing the names of the threads that are in the BLOCKED state.  When you click on the thread name in the graph, that particular thread’s stack trace will be reported in the tool.

Fig: 189 Threads BLOCKED on ‘java.lang.System.getProperty()’ API, reported by fastThread

All these threads entered into the BLOCKED state because of the ‘Camel Thread #6 – backboneThreadPool’ (i.e., Red color node in the graph). Here is the initial few lines of this thread’s stack trace:

Camel Thread #6 – backboneThreadPool

Stack Trace is:

at java.util.Hashtable.get(Hashtable.java:362)

- locked <0x0000000080f5e118> (a java.util.Properties)

at java.util.Properties.getProperty(Properties.java:969)

at java.util.Properties.getProperty(Properties.java:988)

at java.lang.System.getProperty(System.java:756)

at net.java.ao.atlassian.ConverterUtils.enforceLength(ConverterUtils.java:16)

at net.java.ao.atlassian.ConverterUtils.checkLength(ConverterUtils.java:9)

:

:

Fig: Stack trace of the thread which acquired the LOCK

From the stack trace, you can notice that this thread was invoking the ‘java.lang.System.getProperty()’ API. Since ‘java.lang.System.getProperty()’ API underlyingly uses ‘java.util.Hashtable.get()’ API (which is a 

is a synchronized API call). Thus ‘Camel Thread #6 – backboneThreadPool’ will be the only thread allowed to enter this method. Below are the initial few lines of couple of threads (out of 189 threads) who are in BLOCKED state because they are waiting to enter the ‘java.util.Hashtable.get()’ API.

http-nio-8080-exec-293 

Stack Trace is:

java.lang.Thread.State: BLOCKED (on object monitor)

at java.util.Hashtable.get(Hashtable.java:362)

- waiting to lock <0x0000000080f5e118> (a java.util.Properties)

at java.util.Properties.getProperty(Properties.java:969)

at java.util.Properties.getProperty(Properties.java:988)

at java.lang.System.getProperty(System.java:756)

at net.java.ao.atlassian.ConverterUtils.enforceLength(ConverterUtils.java:16)

at net.java.ao.atlassian.ConverterUtils.checkLength(ConverterUtils.java:9)

:

:

Fig: Stack trace of one of the BLOCKED threads waiting for the LOCK

http-nio-8080-exec-279 

Stack Trace is:

java.lang.Thread.State: BLOCKED (on object monitor)

at java.util.Hashtable.get(Hashtable.java:362)

- waiting to lock <0x0000000080f5e118> (a java.util.Properties)

at java.util.Properties.getProperty(Properties.java:969)

at java.util.Properties.getProperty(Properties.java:988)

at java.lang.System.getProperty(System.java:756)

at org.ofbiz.core.entity.EntityFindOptions.<init>(EntityFindOptions.java:124)

:

:

Fig: Stack trace of another BLOCKED thread waiting for the LOCK

Since this ‘java.lang.System.getProperty()’ API was present in the critical code path, multiple threads were trying to invoke it. Thus, all those 189 threads which were trying to invoke this API were put into BLOCKED state. Ultimately overall application response time was degraded. 

What is the solution?

Since System properties don’t change during runtime, we don’t have to keep invoking ‘java.lang.System.getProperty()’ API on every single transaction. Rather, we can invoke ‘java.lang.System.getProperty()’ API once, cache its value, and return the cached value on all future calls, as shown in the below code snippet.

private static String app = System.getProperty("appName");

   

public static String getAppName() {

   

  return app;

}

If you notice the above code, ‘’java.lang.System.getProperty()’ is now assigned to a static member variable. It means this API will be called during application startup time, that too only once. From that point, if anyone invokes the getAppName() API, he will be returned the cached value. Thus, application threads will not be put into BLOCKED state at runtime. This simple change can improve the application’s overall response time.

Source: javacodegeeks.com

Continue reading

Java IO FileReader Class

FileReader is a class in the java.io package which can be used to read a stream of characters from the files. This class uses either specified charset or the platform’s default charset for decoding from bytes to characters.

Charset: The Charset class is used to define methods for producing encoders and decoders and for recovering several names combined with the charset.

Default Charset: The default charset is defined during implicit computer start-up and it depends on the locale and charset of the underlying operating system.

The following image shows the Hierarchical Flow of FileReader class.

Constructors 

The Constructors inside FileReader are shown in the table below.

Constructor	Description
FileReader(File file)	Creates a new FileReader with given File to read (using default charset)
FileReader(FileDescriptor fd)	Creates a new FileReader with given FileDescriptor to read (using default charset)
FileReader(File file, Charset charset)	Creates a new FileReader with given File to read (using given charset)
FileReader(String filename)	Creates a new FileReader with given FileName to read (using default charset)
FileReader(String filename, Charset charset)	Creates a new FileReader with given File to read (using given charset)

Methods

The methods under FileReader are shown in the table below.

◉ read(): The read() method reads and passes a single character or -1 if the stream is ended.

◉ read(char[] charBuffer, int offset, int length): It reads a stream of characters and stores them in the given Character Buffer. Offset is the position at which it starts reading and Length is the total number of characters to be read. It passes plenty of characters read or -1 if the stream is ended.

◉ ready(): It tells whether the stream is ready to be read. A stream is said to be ready if its input buffer is not blank or empty.

◉ getEncoding(): The getEncoding() is used to return the title of the character encoding which is being used by the stream.

◉ close(): It closes the stream and releases the system resources associated with it.

// Java program to show the usage of

// IO FileReader Class

import java.io.*;

class OJC {

public static void main(String[] args)

{

try {

FileReader fileReader

= new FileReader("ojc.txt");

System.out.println("Reading char by char : \n");

int i;

while ((i = fileReader.read()) != -1) {

System.out.print((char)i);

}

System.out.println("Reading using array : \n");

char[] charArray = new char[10];

fileReader.read(charArray);

System.out.print(charArray);

fileReader.close();

System.out.println("FileReader closed!");

}

catch (Exception e) {

System.out.println(e);

}

}

}

Output:

Reading char by char :

OracleJavaCertified

Reading using array : 

OracleJavaCertified

FileReader closed!

Source: geeksforgeeks.org

Continue reading

Google Cloud Deploy – CD for a Java based project

This is a short write-up on using Google Cloud Deploy for Continuous Deployment of a Java-based project. 

Google Cloud Deploy is a new entrant to the CD space. It facilitates a continuous deployment currently to GKE based targets and in future to other Google Cloud application runtime targets.

Let’s start with why such a tool is required, why not an automation tool like Cloud Build or Jenkins. In my mind it comes down to these things:

1. State – a dedicated CD tool can keep state of the artifact, to the environments where the artifact is deployed. This way promotion of deployments, rollback to an older version, roll forward is easily done. Such an integration can be built into a CI tool but it will involve a lot of coding effort.

2. Integration with the Deployment environment – a CD tools integrates well the target deployment platform without too much custom code needed.

Target Flow

I am targeting a flow which looks like this, any merge to a “main” branch of a repository should:

1. Test and build an image

2. Deploy the image to a “dev” GKE cluster

3. The deployment can be promoted from the “dev” to the “prod” GKE cluster

Building an Image

Running the test and building the image is handled with a combination of Cloud Build providing the build automation environment and skaffold providing tooling through Cloud Native Buildpacks. It may be easier to look at the code repository to see how both are wired up – https://github.com/bijukunjummen/hello-skaffold-gke

Deploying the image to GKE

Now that an image has been baked, the next step is to deploy this into a GKE Kubernetes environment.  Cloud Deploy has a declarative way of specifying the environments(referred to as Targets) and how to promote the deployment through the environments. A Google Cloud Deploy pipeline looks like this:

apiVersion: deploy.cloud.google.com/v1beta1

kind: DeliveryPipeline

metadata:

  name: hello-skaffold-gke

description: Delivery Pipeline for a sample app

serialPipeline:

  stages:

    - targetId: dev

    - targetId: prod

---

apiVersion: deploy.cloud.google.com/v1beta1

kind: Target

metadata:

  name: dev

description: A Dev Cluster

gke:

  cluster: projects/a-project/locations/us-west1-a/clusters/cluster-dev

---

apiVersion: deploy.cloud.google.com/v1beta1

kind: Target

metadata:

  name: prod

description: A Prod Cluster

requireApproval: true

gke:

  cluster: projects/a-project/locations/us-west1-a/clusters/cluster-prod

The pipeline is fairly easy to read. Target(s) describe the environments to deploy the image to and the pipeline shows how progression of the deployment across the environments is handled. 

One thing to notice is that the “prod” target has been marked with a “requires approval” flag which is a way to ensure that the promotion to prod environment happens only with an approval. Cloud Deploy documentation has a good coverage of all these concepts. Also, there is a strong dependence on skaffold to generate the kubernetes manifests and deploying them to the relevant targets.

Given such a deployment pipeline, it can be put in place using:

gcloud beta deploy apply --file=clouddeploy.yaml --region=us-west1

Alright, now that the CD pipeline is in place, a “Release” can be triggered once the testing is completed in a “main” branch, a command which looks like this is integrated with the Cloud Build pipeline to do this, with a file pointing to the build artifacts:

gcloud beta deploy releases create release-01df029 --delivery-pipeline hello-skaffold-gke --region us-west1 --build-artifacts artifacts.json

This deploys the generated kubernetes manifests pointing to the right build artifacts to the “dev” environment

and can then be promoted to additional environments, prod in this instance.

Source: javacodegeeks.com

Continue reading

Difference between JIT and JVM in Java

Java Virtual Machine (JVM) is used in the java runtime environment(JRE). The original JVM was conceived as a bytecode interpreter. This may come as a bit of a surprise because of performance problems. Many modern languages are meant to be compiled into CPU-specific, executable code. The fact that the JVM executes a Java program, however, helps address the major issues associated with web-based applications.

The fact that the JVM executes a Java program also helps to make it stable. Since the JVM is in charge, program execution is controlled by it. Therefore, it is possible for the JVM to build a limited execution area called a sandbox that contains the software, preventing the system from getting unlimited access. Protection is also improved by some limitations in the Java language that exists. Java’s JVM architecture includes a class loader, execution engine, memory field, etc.

In order to understand differences, let’s dig down to the components by illustrating the working of JVM alongside. 

◉ ClassLoader: The class loader has the purpose of loading class files. It helps accomplish three main functions: Loading, Initialization, and Linking.

◉ JVM language Stacks: Java memory stores local variables, and partial results of a computation. Each thread has its own JVM stack, created as the thread is created. When the method is invoked, a new frame is created, and then removed.

◉ Method Area: JVM Method Area specializes in storing the metadata and code-behind files for Java applications.

◉ PC Registers: The Java Virtual Machine Instruction address currently being executed is saved by PC registers. Each thread in Java has its own separate PC register.

◉ Heap: In a heap are saved all objects, arrays, and instance variables. This memory is shared between several threads.

◉ Execution Engine: It is a form of software used for the testing of software, hardware, or complete systems. The test execution engine never carries any information concerning the product being tested.

◉ Native Method Libraries which are the Executing Engine needs Native Libraries (C, C++) and the native method interface which is a framework for programming is the Native Method Interface. This enables the Java code that runs in a JVM to call libraries and native applications. Also, the native method stacks have a native code command depending on the native library. It assigns storage to native heaps or uses any stack type.

Just In Time(JIT) compiler

While Java was developed as an interpreted language, in order to improve performance, there is nothing about Java that prevents bytecode compilation into native code on the fly. For that reason, not long after Java’s initial release, the HotSpot JVM was released. A just-in-time (JIT) bytecode compiler is included in HotSpot. A Just In Time(JIT) compiler is part of the JVM and on a piece-by-piece demand basis, selected portions of bytecode are compiled into executable code in real-time. That is, as is necessary during execution, a JIT compiler compiles code. In addition, not all bytecode sequences are compiled, only those that will benefit from the compilation. The just-in-time method, however, still yields a major boost in inefficiency. The portability and safety function still exists even though dynamic compilation is applied to bytecode since the JVM is still in control of the execution environment.

In order to understand differences, let’s dig down to the components by illustrating the working of JIT alongside.

Interpreting the bytecode, the standard implementation of the JVM slows the execution of the programs. JIT compilers interact with JVM at runtime to improve performance and compile appropriate bytecode sequences into native machine code.

Hardware is interpreting the code instead of JVM (Java Virtual Machine). This can lead to performance gains in the speed of execution. This can be done per-file, per-function, or maybe on any arbitrary code fragment; the code is often compiled when it’s close to being executed (hence the name “just-in-time”), and then cached and reused later without having to be recompiled. It performs many optimizations: data analysis, translation from stack operations to registry operations, reduction of memory access by registry allocation, elimination of common sub-expressions.

Hence, from the above knowledge, we landed on the conclusive differences between them as mentioned in the table below:

JVM	JIT
JVM stands for Java Virtual Machine.	JIT stands for Just-in-time compilation.
JVM was introduced for managing system memory and providing a transportable execution environment for Java-based applications	JIT was invented to improve the performance of JVM after many years of its initial release.
JVM consists of many other components like stack area, heap area, etc.	JIT is one of the components of JVM.
JVM compiles complete byte code to machine code.	JIT compiles only the reusable byte code to machine code.
JVM provides platform independence.	JIT improves the performance of JVM.

Source: geeksforgeeks.com

Continue reading

Difference Between 32-bit and 64-bit JVM in Java

One does not need to know the difference unless developing a performance-critical application. The minor distinction between 32-bit and 64-bit JVMs would make little difference in your application.

Now coming onto the differences where we will be listing out some key differences between 32-bit and 64-bit Java Virtual Machines are listed below in which we are comparing them alongside based on the concessive factors which are as follows:

1. In a 64-bit JVM, you can specify more memory for heap size than in a 32-bit JVM; for example, in a 32-bit JVM, the theoretical maximum memory limit is 4GB, whereas 64-bit is much higher.

2. The 64-bit JVM is especially useful for Java applications with large heaps, such as those that use more than 100 GB of memory as a maximum.

3. Because the size of the OOP (Ordinary Object Pointer) has increased from 32 to 64 bits, the same Java application will use more memory in the 64-bit JVM than in the 32-bit JVM. You can get away with it if you use the JVM option -XXCompressedOOP, which tells JVM to use 32-bit pointers.

4. The next major change which is seen is that in the 64-bit JVM architecture is the object header size, which is now 12 bytes instead of 8 bytes in the 32-bit JVM. Another change is the size of internal references, which can now be up to 8 bytes, whereas the 32-bit JVM can only be up to 4 bytes.

5. There is a separate installer for the 32-bit and 64-bit JVM’s.

6. Client JVM is only available for 32-bit JVM and not for 64-bit.

As above, we have seen such differences but do remember a note on how can 64-bit JVM performance be slower than 32-bit JVM?

This is because each native pointer in the system takes up eight bytes instead of four. The loading of this additional data increases memory usage, which results in slightly slower execution depending on how many pointers are loaded during your Java program’s execution. The Java virtual machine gains some extra registers that it can use to create more efficient native instruction sequences. When comparing 32-bit to 64-bit execution speed, these extra registers increase performance to the point where there is often no performance loss at all.

Certain points are there to be taken into consideration while migrating from a 32-bit JVM to a 64-bit JVM are as follows:

◉ Garbage collector pause time

◉ Native library

Factor 1: GC Pause times

The primary motivation for switching from 32-bit to 64-bit JVM is to increase heap size (i.e. -Xmx). When you increase heap size, your GC pause times will automatically increase because there is no more garbage in memory to clear. Before performing the migration, you must perform proper GC tuning; otherwise, your application may experience a pause of several seconds to a few minutes. To come up with the right GC settings for the newly increased heap size, you can use tools like GCeasy.

Factor 2: Native Library

If your application accesses native libraries through the Java Native Interface (JNI), you’ll need to upgrade the native libraries as well because only 32-bit native libraries can be used by 32-bit JVM. Similarly, a 64-bit JVM can only use native libraries that are 64-bit.

Note: When should I use a 32-bit or 64-bit Java virtual machine?

◉ If your application’s heap size (i.e. -Xmx) is less than 2GB, it’s a no-brainer. Use a 32-bit JVM. (< 2GB Memory)

◉ If your application requires more than 2GB of memory, it’s a no-brainer. Definitely go with 64-bit JVM (> 2GB memory)

Continue reading

Character isDigit() method in Java with examples

1. The java.lang.Character.isDigit(char ch) is an inbuilt method in java which determines whether a specified character is a digit or not. There are few conditions that a character must accomplish to be accepted as a digit. That is if the general category type of a character, provided by Character.getType(ch), is DECIMAL_DIGIT_NUMBER, then the character is a digit.

Some Unicode character ranges that contain digits:

From ‘\u0030’ to ‘\u0039’ : ISO-LATIN-1 digits (‘0’ through ‘9’)

From ‘\u0660’ to ‘\u0669’ : Arabic-Indic digits

From ‘\u06F0’ to ‘\u06F9’ : Extended Arabic-Indic digits

From ‘\u0966’ to ‘\u096F’ : Devanagari digits

From ‘\uFF10’ to ‘\uFF19’ : Fullwidth digits

Apart from the above mentioned ranges, many other character ranges contain digits as well.

Syntax:

public static boolean isDigit(char ch)

Parameter: This method accepts character parameter ch as an argument, which is to be tested.

Return value: This method returns a boolean value. It returns True if ch is digit, else False.

Note: This method cannot handle supplementary characters. To support all Unicode characters, including supplementary characters, use the isDigit(int) method.

Below programs illustrate the above method:

Program 1:

// Java program to illustrate the

// Character.isDigit() method

import java.util.*;

import java.lang.*;

public class OJC {

public static void main(String[] args)

{

// two characters

char c1 = 'A', c2 = '4';

// Function to check if the character

// is digit or not

System.out.println(

c1 + " is a digit -> "

+ Character.isDigit(c1));

System.out.println(

c2 + " is a digit -> "

+ Character.isDigit(c2));

}

}

Output:

A is a digit -> false

4 is a digit -> true

Program 2:

// Java program to illustrate the

// Character.isDigit() method

import java.util.*;

import java.lang.*;

public class OJC {

public static int search_digit(String s)

{

// Function to check if is digit

// is found or not

for (int i = 0; i < s.length(); i++) {

if (Character.isDigit(

s.charAt(i))

== true) {

// return position of digit

return i + 1;

}

}

// return 0 if digit not present

return 0;

}

public static void main(String[] args)

{

// Array of strings

String[] arr = { "ABC4DEF", "QWERTY" };

// To store the position of digit

int index = 0;

// Traverse the array arr[] to find digit

// within it's elements

for (String x : arr) {

index = search_digit(x);

if (index != 0) {

System.out.println(

"Digit found at : "

+ (index)

+ "th position.");

}

else {

System.out.println(

"Digit not present.");

}

}

}

}

Output:

Digit found at : 4th position.

Digit not present.

2. The java.lang.Character.isDigit(int codePoint) is an inbuilt method in java which determines whether the specified Unicode code point character of integer type is a digit or not.

There are few conditions that a character must accomplish to be accepted as a digit. That is if the general category type of a character, provided by getType(codepoint), is a DECIMAL_DIGIT_NUMBER, then the character is a digit. Some Unicode character ranges that contain digits:

From ‘\u0030’ to ‘\u0039’ : ISO-LATIN-1 digits (‘0’ through ‘9’)

From ‘\u0660’ to ‘\u0669’ : Arabic-Indic digits

From ‘\u06F0’ to ‘\u06F9’ : Extended Arabic-Indic digits

From ‘\u0966’ to ‘\u096F’ : Devanagari digits

From ‘\uFF10’ to ‘\uFF19’ : Fullwidth digits

Apart from the above mentioned ranges, many other character ranges contain digits as well.

Syntax:

public static boolean isDigit(int codePoint)

Parameter: This method accepts unicode character parameter codePoint of integer type as an argument, which is to be tested.

Return value: This method returns a boolean value. It returns True if the specified character is digit, else it returns False.

Below programs illustrate the above method:

Program 1:

// This program demonstrates the use of

// isDigit(int codePoint) method of Character class.

import java.util.*;

public class OJC {

public static void main(String[] args)

{

// create codePoints

int cp1 = 57;

int cp2 = 84;

// Check whether the codePoints

// are digit or not.

System.out.println(

"The codePoint cp1 is a digit -> "

+ Character.isDigit(cp1));

System.out.println(

"The codePoint cp2 is a digit -> "

+ Character.isDigit(cp2));

}

}

Output:

The codePoint cp1 is a digit -> true

The codePoint cp2 is a digit -> false

Program 2:

// This program demonstrates the use of

// isDigit(int codePoint) method of

// Character class.

import java.util.*;

public class Main {

public static void main(String[] args)

{

// create codePoints

int cp1 = 0x50;

int cp2 = 0x06f8;

// Check whether the codePoints

// are digit or not.

System.out.println(

"The codePoint cp1 is a digit -> "

+ Character.isDigit(cp1));

System.out.println(

"The codePoint cp2 is a digit -> "

+ Character.isDigit(cp2));

}

}

Output:

The codePoint cp1 is a digit -> false

The codePoint cp2 is a digit -> true

Source: geeksforgeeks.org

Continue reading

J2SE vs J2ME vs J2EE….What’s the difference?

This article’s main focus is to inform the readers about Java’s different versions and how are they different.

First of all, let’s understand what Java is really about. Java is basically a general purpose, high level programming language, which is widely used for development of application softwares.

Read More: Oracle Java Certification Practice Exams

It’s used in a wide variety of platforms such as mobile phones, embedded systems, web pages, servers and much more. Due to its cross platform compatibility, it makes it ideal for working across platforms. According to Oracle, there are about 9 million Java developers till date.

Java features

◉ Simple, Object-oriented and familiar

◉ Robust and Secure

◉ Architecture-neutral and portable

◉ High performance

◉ Firstly java is compiled to bytecode, which then either compiled, or interpreted depending on mood of JIT.

Some interesting facts about Java-

◉ Java’s old name was OAK (because of the Oak tree growing outside developer’s house).

◉ Coffee Mug was deployed as Java’s symbol, because the developers of Java drank and loved coffee.

◉ It was originally developed by Sun Microsystems, but later bought by Oracle.

◉ First major JDK (Java Development Kit) 1.0 was released on January 21, 1996.

◉ Android, one of the most famous mobile OS, is based on Java.(Android SDK also uses Java)

◉ Java has no concept of pointers unlike its predecessors.

◉ “JAVA” has nothing to do with “JAVASCRIPT”, which is a scripting language, and not a programming language.

◉ Java is still no. 2 development platform worldwide

◉ There are currently 9 million Java developers, all around the globe.

Now, let’s understand about different editions of Java platform-

◉ J2SE(Java Platform, Standard Edition)

Also known as Core Java, this is the most basic and standard version of Java.It’s the purest form of Java, a basic foundation for all other editions.

It consists of a wide variety of general purpose API’s (like java.lang, java.util) as well as many special purpose APIs

J2SE is mainly used to create applications for Desktop environment.

It consist all the basics of Java the language, variables, primitive data types, Arrays, Streams, Strings Java Database Connectivity(JDBC) and much more. This is the standard, from which all other editions came out, according to the needs of the time.

The famous JVM of Java, the heart of Java development, was also given by this edition only.It’s because of this feature, that Java has such a wide usage.

◉ J2ME(Java Platform, Micro Edition)

This version of Java is mainly concentrated for the applications running on embedded systems, mobiles and small devices.(which was a constraint before it’s development)

Constraints included limited processing power, battery limitation, small display etc.

Also, the J2ME apps help in using web compression technologies, which in turn, reduce network usage, and hence cheap internet accessibility.

J2ME uses many libraries and API’s of J2SE, as well as, many of it’s own.

The basic aim of this edition was to work on mobiles, wireless devices, set top boxes etc.

Old Nokia phones, which used Symbian OS, used this technology.

Most of the apps, developed for the phones(prior to smartphones era), were built on J2ME platform only(the .jar apps on Nokia app store).

◉ J2EE(Java Platform, Enterprise Edition)

The Enterprise version of Java has a much larger usage of Java, like development of web services, networking, server side scripting and other various web based applications.

J2EE is a community driven edition, i.e. there is a lot of continuous contributions from industry experts, Java developers and other open source organizations.

J2EE uses many components of J2SE, as well as, has many new features of it’s own like Servlets, JavaBeans, Java Message Services, adding a whole new functionalities to the language.

J2EE uses HTML, CSS, JavaScript etc., so as to create web pages and web services. It’s also one of  the most widely accepted web development standard.

There are also many languages like .net and php, which can do that work, but what distinguishes it from other languages is the versatility, compatibility and security features, which are not that much prominent in other languages.

Nowadays, developers are going more towards this edition, as it more versatile and web friendly that it’s other counterparts.

Apart from these three versions, there was another Java version, released Java Card.

This edition was targeted, to run applets smoothly and securely on smart cards and similar technology.

Portability and security was its main features.

JavaFX is another such edition of Java technology, which is now merged with J2SE 8.It is mainly used, to create rich GUI (Graphical User Interface) in Java apps.

It replaces Swings (in J2SE), with itself as the standard GUI library.

It is supported by both Desktop environment as well as web browsers.

PersonalJava was another edition, which was not deployed much, as its function was fulfilled by further versions of J2ME. Made to support World Wide Web (and Java applets) and consumer electronics.

PersonalJava was also used for embedded systems and mobile. But, it was discontinued in its earlier stages.

Source: geeksforgeeks.org

Continue reading

Oracle India Pvt Ltd Interview Experience for Full Stack Java Developer

Round 1(Online Assessment and Coding Challenge–90 minutes): This assessment consisted of two different online programmatic sets of coding challenges and both are important and have to answer them.

Expectations:

◉ Ability to identify problem types and apply conventionally known techniques to solve them.

◉ Usage of optimal Data Structures for the problem statement

◉ Demoable code

◉ Functional Correctness and Completeness

◉ Modularity and Extensibility

◉ Good understanding of Java/ J2EE, Spring Boot, Restful Services & Webservices, Kubernetes, and PL/SQL (SQL is also ok)

Read More: 1Z0-900: Java EE 7 Application Developer

1. Java/ J2EE (Online Assessment 30 minutes): This section contains three different types of programmatic skills, and each one has a different set of questions. Each Section has multiple choice question which needs to answer, and there is no negative marking.

◉ Java (12 MCQ): This assessment includes basic understanding of core java, which contain 12 multiple choice question and will need to complete in 12 minutes.

Expectations:

◉ Basic Knowledge of java programming

◉ Multithreading

◉ Exception Handling

◉ Inheritance

◉ Java 8 Functionality

◉ Overloading

◉ J2EE(8 MCQ): This assessment includes a basic understanding of J2EE concepts, which contain 8 multiple choice questions and will need to complete within 8 minutes.

Expectations:

◉ Java Servlets.

◉ JavaServer Pages (JSP)

◉ Enterprise JavaBeans (EJB)

◉ Java Message Service (JMS)

◉ Java Naming and Directory Interface (JNDI)

◉ Java Database Connectivity (JDBC)

◉ Restful Services & Webservices(12 MCQ): This assessment includes a basic understanding of Restful Services & Webservices concepts, which contain 12 multiple choice questions and will need to complete within 12 minutes.

Expectations:

◉ Basic understanding of SOAP

◉ Basic Understanding of Restful

◉ Basic Understanding of JSON

◉ Request Headers

◉ Resources

◉ Request Body

◉ Response Status codes

◉ POST,GET, PUT and DELETE Method

2. Oracle Coding Challenge (60 mins): This assignment contains two different sets of programming questions, which need to complete in 60 minutes. Each one will be challenging, and need to choose the strategy to solve this problem wisely, as time is only 60 minutes.

Expectations:

◉ How good is your algorithm, technique you apply to make the app faster, etc?

◉ Scalability

◉ Testability

◉ Design patterns

◉ Demoable code

◉ Clear Separation of Concerns (Good Class Design)

◉ Functional Correctness and Completeness

◉ Readability

◉ Modularity and Extensibility

◉ Exception handling

Task 1: Girls in Tech Hackathon

◉ Problem Statement:

The Girl in Tech Hackathon is code-a-thon where developers, designers, scientists, students, entrepreneurs, and educators gather to collaborate on projects including applications, software, hardware, data visualization, and platform solutions. The Participants are sitting around the table, and they are numbered from team1 to team n in the clockwise direction. This means that the Participants are numbered 1,2, ..,n-1,n and participants 1 and n are sitting next to each other. After the Hackathon duration, judges started reviewing the performance of each participant. However, some participants have not finished the project. Each participant needs ti extra minute to complete their project. Judges started reviewing the projects sequentially in the clock direction, starting with team x, and it takes them exactly 1 minute to review each project. This means team x gets no extra time to work, whereas team x +1 gets 1 min more to work and so on. Even if the project is not completed by the participant, but still the judges spend 1 min to understand the idea and rank the participant.

◉ Input Format:

The first line contains a single positive integer, n, denoting the number of participants in the hackathon. Given the values of t1,t2, t3,… tn extra time requires by each participant to complete the project. You have to guide judges in selecting the best team x to start reviewing the project so that number of participants able to complete their project is maximal.

◉ Output Format:

Print x on a new line. If there are multiple such teams, 

select the smallest one.

Constraints:

1<=n<=9*10^5

0<=ti<=n

Sample Input:

3

1 0 0

Sample Output:

2

import java.io.BufferReader;

import java.io.InputStreamReader;

Class Test

{

/* Read input from stdin and provide input before

* running*/

BufferedReader br = new BufferedReader(

new InputStreamReader(System.in)) String line

= br.readLine();

for (int i = 0; i < N; i++) {

System.out.println(“Hello Word”);

}

}

Task 2: Stella and colorful tree

◉ Problem Statement:

While returning from Byteland, Stella got one tree with N nodes from her friend over there. All nodes in this tree are colorless and Stella decided to fill colors to make it colorful. Stella wants it to look beautiful and decided to color it in such a way that any 2 nodes u and v with the shortest distance between u and v <=2 can not be of the same color. She is wondering how many different colors she needs if she fills optimally.

◉ Input Format:

The first line contains a single integer n ( 3 <=n<100) – the number of nodes in the tree. Each of the next(n-1) lines contains two integers x and y(1<=x, y<=n) – the indices of two nodes directly connected by an edge. It is guaranteed that any node is reachable from any other using the edges.

◉ Output Format:

In the first line print single integer k – the minimum number of colors Stell has to use.

Sample Input 1:

           3

          2 3

          1 3

Sample Output 1:

          3

 Explanation Output 1:

           Tree is like

           1 -> 3 ->2

We can color as follows

         1: Color a

         3: Color b

         2 : Color c

         Total 3 colors

Sample Input 2:

           5

          2 1

          3 2

          4 3

          5 4

Sample Output 2

           3

Explanation Output2: 

          Tree is like:

          1 -> 2 ->3 -> 4 -> 5

         We can color as follows

         1: Color a

         2: Color b

         3 : Color c

         4: Color a

         5 : Color b

         Total 3 colors.

import java.io.BufferReader;

import java.io.InputStreamReader;

Class Test {

/* Read input from stdin and provide input before running*/

BufferedReader br = new BufferedReader(new InputStreamReader(System.in))

String line = br.readLine();

for (int i =0 ; i< N; i++){

System.out.println(“Hello Word”);

}

}

Source: geeksforgeeks.org

Continue reading