Unique Java Card verification and deployment model

A key concept in security is "defence in depth”: multiple controls must be performed in sequence to guaranty Confidentiality, Integrity and Availability of sensitive assets.

Java Card products and associated security services are examples of such assets. They are a critical enabler in our day-to-day lives: to pay at a shop, make a phone call, cross a border with a passport or to provide trusted and genuine data to IoT clouds for AI processing. The deployment of Java Card applications relies on an established ecosystem of hundreds of companies and organizations, organized around security practices that guarantee this defence in depth. The three pillars of this deployment model are code verification, chain of trust and certification.​

 

Java Security and verification

As with any Java-based Virtual Machine, a fundamental feature of the Java Card Virtual Machine is the security provided by bytecode verification. A verifier checks the structure of a Java Card Converted Applet (CAP) file - the file format for Java Card applications - and perform bytecode verification ensuring type safety. Code verification is always a mandatory step. It must be performed in the deployment process of an application to prevent against security risks induced by malformed code. We will see however, that Java Card offers some flexibility to determine when and how verification must be applied.

The Java Card Virtual Machine, Runtime Environment and APIs are designed to run security services on tamper-resistant, secure hardware, and in many cases with limited memory and CPU resources. Some secure elements for example may only have 2 or 4 KB of RAM, and 16-32 bit CPUs. On very resource-constrained hardware, a Java Card implementation may not have enough memory to perform verification on the device itself. To address this scenario, the Java Card specification includes a stand-out feature in allowing a split-VM architecture: verification can either be processed inside the device (on-device or on-card verification) as is the case for the standard Java Virtual Machine for example, or outside the device with an off-device or off-card verifier tool coming with an abstract interpreter.

To support that flexibility, Oracle provides the Java Card Off-Card verifier as a standard tool that can be used for off-device verification. Other similar tools may be available from Java Card licensees.

When verification is performed off-device, several security conditions need to be enforced to prevent execution of corrupted code:

◉ The latest version of the verifier tool needs to be used to perform up-to-date security checks. In the case of the Oracle Java Card Verifier, the latest version can be found as a free download on the Oracle website.

◉ Verification must use export files that are binary compatible with API packages installed on the device.

◉ After verification, the CAP file to be executed on the device is not altered in a way that does not satisfy the constraints checked by this verification.

Another aspect of the split-VM architecture is that data needed for verification is optional and packaged separately from the data needed for the actual execution of the code within a CAP file. This design avoids embedding data that would be unused by a product without on-device verification capabilities. The deployment model acknowledges that a Java Card application can be installed by multiple service providers, managing the installation of optional CAP file components (including those used for verification) in a variety of ways, and on Java Card products with different on-device verification capabilities.

As a consequence, even if off-device verification is not strictly a mandate in the specs (it can be done on-device instead), off-device verification has become a pre-requisite in the Java Card deployment ecosystem. Systematic off-card verification ensures that verification is performed, independently of the on-device capabilities of Java Card product that may be rolled out in future phases of deployment.

Chain of Trust and AAA+ service

The second pillar of the deployment model is based on application management  and communication protocols, such as the ones defined by GlobalPlatform, to securely administrate a Java Card product: installation, update, removal of applications and credentials associated with applications. The principle is to enforce a chain of trust starting from the source of a CAP file and based on a AAA+ service: identification, authentication, authorization, Accountability/non-repudiation are guaranteed for each management operation.

CAP files are installed on a Java Card product either at manufacture with specific accreditation and certification, or once deployed in the field by using a Remote Service Manager and through secure channels. In any case, cryptographic keys guarantee an application deployment is secure (confidentiality and integrity) and performed only by an authenticated entity having a granted authorization. In other words, keys are needed to administrate a Java Card product, and it is not possible to install an application without breaking the chain of trust that manages those keys.

The entity or entities deploying applications must anticipate the range of on-device verification capabilities of the targeted Java Card products, and will deploy applications only having the guarantee that the code is verified at some point in time prior its execution either off-device or on-device. As mentioned in the previous section, state of the art is to perform verification of applications off-device prior any deployment to avoid any risk: even if verification is also performed on-device, it prevents from having a corrupted CAP file that may lead to a denial of service for instance.

 

Security Evaluation & Certification

Products certification is the only mean to bring trust in an open ecosystem. Java Card is widely used in Finance, ID, Mobile and IoT markets. Without trust no one can accept to be liable for a given business risk.

To facilitate Common Criteria certification, Oracle provides a Java Card Protection Profile that helps vendors meet the demand of banks, governments, and other secure device issuers for security evaluations. Verification is a mandatory requirement in order to obtain Common Criteria certification, and is required by the Java Card protection profile.

In addition, in order to adhere to hardware and software certification requirements or as an additional product differentiation, Java Card vendors may choose to have additional and different types of security checks that are performed at runtime, focusing on the execution behavior such as:

◉ security counter measures against logical attacks that may happen if the integrity of the flow from verification to the installation is compromised or memory corrupted after code has been installed in the device: protection against stack or objects overflows, invalid execution paths or illegal code jump, illegal entry point access, type confusion ...

◉ or counter measures against physical attacks, faults attacks or side channel attacks that may happen during execution. 

Depending on the deployment scenario (e.g. multiple entities authorized to provide applications for a device), or the condition of utilization of a device (e.g. devices exposed to high risk of physical attacks or lacking hardware countermeasures), application deployers may elect to choose Java Card products with those additional security checks, as an additional protection layer in addition to verification and a chain of trust.

Source: oracle.com

Continue reading

Implement Interface using Abstract Class in Java

Interface contains only abstract methods that can’t be instantiated and it is declared by keyword interface. A class that is declared with the abstract keyword is known as an abstract class in Java. This is a class that usually contains at least one abstract method which can’t be instantiated and It is also possible for the class to have no methods at all. The instance of an abstract class can’t be created.

Now as all methods in an interface are abstract methods therefore we can implement it using Abstract Class.

1. Let’s create an Interface at first:

// creating an interface named ORACLEJAVACERTIFIED 

interface ORACLEJAVACERTIFIED { 

void learnCoding(); 

void learnProgrammingLanguage(); 

void contribute(); 

}

Here the three  non-implemented methods are the abstract methods

2. Now let’s implement the interface in an Abstract class named Student:

// creating an abstract class named Student which is 

// implementing the interface,ORACLEJAVACERTIFIED 

abstract class Student implements ORACLEJAVACERTIFIED { 

// Overriding two methods of the interfacem,ORACLEJAVACERTIFIED

@Override public void learnCoding() 

{ 

System.out.println( 

"Let's make coding a habit with ORACLEJAVACERTIFIED"); 

} 

@Override public void learnProgrammingLanguage() 

{ 

System.out.println( 

"Let's master all fundamentals of java with the help of ORACLEJAVACERTIFIED"); 

} 

}

Here we have overridden two abstract methods of the interface ORACLEJAVACERTIFIED.

3. Now let’s create a class JAVA which extends the abstract class, Student:

As previously mentioned, we can’t create an instance of our abstract class therefore we need to make a non-abstract class.

// creating an non-abstract class 

// JAVA which is extending Student 

class JAVA extends Student { 

// overriding the remaining method of the interface,ORACLEJAVACERTIFIED 

@Override public void contribute() 

{ 

System.out.println( 

"Now let's help others by contributing in ORACLEJAVACERTIFIED"); 

} 

}

Here we have overridden the remaining method of the interface ORACLEJAVACERTIFIED.

Below is the overall implementation of the problem statement:

// Implemention of Interface using Abstract Class in Java 

// Interface ORACLEJAVACERTIFIED 

interface ORACLEJAVACERTIFIED { 

void learnCoding(); 

void learnProgrammingLanguage(); 

void contribute(); 

} 

// Abstract class Student implementing from ORACLEJAVACERTIFIED interface 

abstract class Student implements ORACLEJAVACERTIFIED { 

// Overriding the methods 

@Override public void learnCoding() 

{ 

System.out.println( 

"Let's make coding a habit with ORACLEJAVACERTIFIED"); 

} 

@Override public void learnProgrammingLanguage() 

{ 

System.out.println( 

"Let's master all fundamentals of java with the help of ORACLEJAVACERTIFIED"); 

} 

} 

// Extend the JAVA class by Student abstract class 

class JAVA extends Student { 

@Override public void contribute() 

{ 

System.out.println( 

"Now let's help others by contributing in ORACLEJAVACERTIFIED"); 

} 

} 

// Driver code 

public class Main { 

public static void main(String[] args) 

{ 

// New JAVA object is created 

JAVA oraclejavacertifiedStudent = new JAVA(); 

// Calls to the multiple functions 

oraclejavacertifiedStudent.learnCoding(); 

oraclejavacertifiedStudent.learnProgrammingLanguage(); 

oraclejavacertifiedStudent.contribute(); 

} 

}

Output:

Let's make coding a habit with ORACLEJAVACERTIFIED

Let's master all fundamentals of java with the help of ORACLEJAVACERTIFIED

Now let's help others by contributing in ORACLEJAVACERTIFIED

Source: geeksforgeeks.org

Continue reading

GraalVM Enterprise 22.2—Lower memory, smaller downloads, simpler library usage

The GraalVM Enterprise 22.2 release includes much anticipated Apple M1 support, a significant reduction in the memory requirements of Native Image, a smaller base JDK distribution package, and an exciting new facility to make it easier to use third-party libraries in your Native Image compiled applications.

Apple Silicon M1/M2

If you don't already have an Apple silicon M1/M2 laptop you're probably thinking about joining the many developers who have raved about its excellent performance, low power consumption, and typically silent operation.  Developers who do have one can now try out GraalVM Enterprise 22.2's new experimental support for Apple silicon and see what the combination of cutting-edge hardware and advanced compiler technology can do!  Running GraalVM Enterprise Native Image on Apple silicon is significantly faster than on Intel Macs improving day-to-day developer productivity.

Slimmed Down JDK

In addition to core Java support, GraalVM Enterprise provides many optionally installable packages supporting several programming languages including Python, Ruby, and R.  To make it easier for developers to get just the components they need we've streamlined the base GraalVM Enterprise installation bundle so that it is smaller and more modular.  You can now download just the GraalVM Enterprise JDK to run Java applications on the JVM.  The reduction in size is immediately visible in the download packages.  For example, in the previous 22.1 release the core Linux amd64 download was 518 MB.  In 22.2 the new JDK download for the same OS and architecture is only 217 MB, a reduction of almost 60%!  Being able to download just the JDK is especially useful if you're deploying your Java app in a container where it's important to keep image size low.  If you do want to use Native Image, VisualVM, or any of the GraalVM supported languages, it's easy to install those components on top of the base JDK.  The choice is yours.

Lower Memory Requirements

With every release, GraalVM Native Image get faster, smarter, and leaner.  In the recent past, 21.3 achieved performance on par with the JVM, 22.0 introduced much more user friendly output, 22.1 delivered faster compilations and a new quick build mode to improve the developer experience.  Now in 22.2 Native Image has cut its memory needs in half!  GraalVM Native Image is written in Java and typically more memory for a Java app leads to better performance.  Most developer machines have plenty, but CI/CD build machines (runners) tend to be more constrained.  For example, free GitHub Actions are limited to 7GB and Oracle Cloud Infrastructure DevOps runners are (currently) limited to 8GB.  With the 22.2 release, GraalVM Native Image can be used on both of those CI/CD platforms to successfully build applications without encountering an out-of-memory error.  Of course, you could always pay for bigger build runners, but thanks to lower memory requirements, GraalVM Enterprise 22.2 can help keep your costs down!

Third-Party Libraries and Native Image

GraalVM Native Image takes a closed-world approach to determine what classes, methods, and fields are compiled into a native executable.  Starting from your application entry point, Native Image performs static analysis to determine all the reachable code that needs to be included.  Unreachable code is excluded from the generated native executable.  This is great in general and the approach works very well with modern frameworks such as Micronaut.  However, many libraries and frameworks use dynamic Java features (such as reflection) that obscure code paths from static analysis.  For such libraries it's necessary to provide Native Image with additional reachability metadata to ensure all required code is included in the final executable.

In GraalVM 22.2, to make it easier to use popular libraries that require additional reachability metadata, the Oracle GraalVM team in conjunction with the Spring and Quarkus teams have created a GitHub repository where metadata for popular libraries can be published.  Using this metadata is as easy as setting a property in the GraalVM Native Build Tools Maven or Gradle plugins.  For example, in Gradle you can enable use of the reachability metadata repository with:

graalvmNative {

    metadataRepository {

        enabled = true

    }

}

For more details, see the Maven and Gradle plugin guides and try out an example.

Wrapping Up

Release to release, GraalVM Enterprise delivers additional performance optimizations and improvements in Native Image compilation time, generated executable size, and developer productivity.  For a complete list of all the changes in GraalVM 22.2 browse the release notes.

GraalVM Enterprise is included in the Oracle Java SE Subscription and is available at no additional cost for use on Oracle Cloud Infrastructure. Download the latest release today!

Source: oracle.com

Continue reading

Quiz yourself: Java’s sealed classes and instanceof checks

What does the Java compiler do when it encounters an instanceof expression?

Given the full code of an interface and three classes

public interface Loggable {

    static boolean isLoggable(Process p) {

        return p instanceof Loggable;

    }

}

sealed class Process permits SlowProcess, FastProcess {

}

final class SlowProcess extends Process {

}

non-sealed class FastProcess extends Process {

}

Which statement is true? Choose one.

A. The code compiles successfully as it is.

B. In order to make the code compilable, the final modifier from SlowProcess class must be removed.

C. In order to make the code compilable, the Process class must implement the Loggable interface.

D. In order to make the code compilable, the non-sealed modifier from FastProcess class must be replaced with the final modifier.

Answer. This question explores limitations added by sealed classes on instanceof checks.

The instanceof expression tests a value against a type. When the compiler comes across an instanceof expression, the compiler first determines if the expression can be shown to be definitely false by static analysis. In such a case, the expression causes a compilation error. A readily understood example of this kind of impossible instanceof is illustrated by the following code:

void compilerError(String s) {

  // compiler rejects this instanceof test

  boolean impossible = s instanceof StringBuilder;

The analysis is a little more subtle where interfaces are concerned, and more examples can help clarify the issue. First, the following example compiles successfully:

interface SomeInterface {

  void doStuff();

}

// and later the test:

void test(BufferedWriter x) {

  boolean test = x instanceof SomeInterface;

The reason this compiles is that even though SomeInterface is clearly a new interface and BufferedWriter does not implement it, the BufferedWriter class is not final. That means it’s possible that elsewhere, or in the future, a subclass of BufferedWriter might exist that implements SomeInterface. Because the compiler doesn’t know, it doesn’t signal a compilation error.

The next example shows another use of instanceof that fails to compile.

void compilerError(String x) {

  boolean test = x instanceof Runnable;

In this case, Runnable is an interface and String does not implement Runnable. At this point, the code seems very similar to the previous example. However, this example fails because String is a final class, and because it’s final, there is no chance of a subclass existing elsewhere. Therefore, there is no chance that a subclass exists that implements Runnable.

This type of logic is also applied to the situation in this exam question.

The instanceof expression in the question tests a reference of type Process to see if the object referred to by that reference implements the Loggable interface. Now, in the typical situation, all types that can ever be assignment-compatible with a sealed class will be known to the compiler, and if none implements the interface in question, the compiler could reject the code outright.

However, in this case, the FastProcess class is marked non-sealed, and because of this, it’s possible for this class to have subclasses that are not known to the compiler at this time, and those subclasses might possibly implement the Loggable interface. Because of this possibility, the compiler accepts the code and compiles the test as written. Therefore, the code will compile successfully as it is, and option A is correct.

The subclasses of a sealed class must explicitly list one of these modifiers: sealed, non-sealed, or final. Removing the final keyword would cause an error, and from this you can determine that option B is incorrect.

Option C proposes a solution to fix a compilation error, but as you have already seen, there’s nothing wrong with the code. Implementing the Loggable interface by the Process class would be entirely valid but is not required to fix the code. Because of this, you can determine that option C is incorrect.

Option D suggests replacing non-sealed with the final modifier. However, this would guarantee that no subtype of Process could exist that would pass the instanceof test—and therefore the change will actually result in compilation failure. This tells you that option D is incorrect.

Conclusion. The correct answer is option A.

Source: oracle.com

Continue reading

Go deep at JavaOne: 20 developer sessions that caught my eye

What are the latest and greatest features of Java? Where is the platform going? How can you leverage Java’s capabilities to build better application—while also enhancing your own skills as a developer?

You’ll find these topics addressed in the technical learning sessions, labs, workshops, and solutions keynotes at the JavaOne Conference, October 17-20, 2022, in Las Vegas.

The conference offers 135 sessions covering all aspects of the language and run-time platform, as well as interoperability and integration with other technologies such as Linux, GitHub, and Spring Boot.

Many of the session leaders are engineers working in the Oracle Java Platform Group, and many also come from the broader community. For example, you can learn from a rock star in the Java world, Venkat Subramaniam, president of Agile Developer Inc., by catching his class “Functional Programming Idioms in Java.”

By the way, JavaOne is collocated with the Oracle CloudWorld Conference, and as an attendee of JavaOne, you can welcome to attend any of the CloudWorld sessions, keynotes, and other events.

Here are some of the JavaOne sessions that I personally find most interesting, but feel free to peruse the entire catalog—or just jump in and register now:

Java First. Java Always.

Modern application development is unrecognizable without Java. For more than 25 years, Java has empowered developers to create the next generation of rich, scalable, and secure applications. In this keynote, learn how Oracle’s ongoing Java leadership and stewardship is creating a contemporary language and platform that helps developer productivity.

Data-Oriented Programming with Records, Sealed Classes, Text Blocks, and More

Java has undergone rapid evolution in the past several years. Many of the new features, while surely useful on their own, are designed to work together. See how three of the recent features—records, sealed classes, and pattern matching—work together to enable a data-oriented style of programming, which is a good match for today's cloud applications.

Developing Long-Lasting Java Microservices

Modern Java development is about simplicity and productivity; the days of ceremony are long gone. We explore what can make an application "modern" and, more importantly, which code practices can help sustain that "modern" feeling—and keep the "legacy" out. See code examples and their consequences (based on code from a global financial super-app), and modern Java Development Kit, naturally.

Evolving the Security of the Java Platform

Maintaining and improving the security of the Java Platform is an essential and continuous process. We discuss recent improvements to the security and cryptographic APIs and libraries, as well as the process and changes made to update releases via the Java Cryptographic Roadmap.

CI/CD, Github Actions, and GraalVM Native Image

For cloud applications, generating a native executable using GraalVM Native Image is often the final build step. Fortunately, new GraalVM Native Image support for GitHub actions makes it easy to incorporate ahead-of-time compilation into a GitHub build pipeline. We look at incorporating GraalVM Native Image compilation into continuous integration and continuous delivery pipelines—including GitHub with GitHub actions—along with generating executables for multiple platforms such as Windows, macOS, and Linux.

Accelerate Java Cloud Native DevOps with Oracle Linux and Oracle VM VirtualBox 

How do you simplify Java cloud native development and deployment? Oracle Linux offers an open, integrated operating environment with application development tools, management tools, containers, and orchestration capabilities. Plus, there are open-source Cloud Native Computing Foundation projects such as Kubernetes, RunC, CRI-O, Kata Containers, and Istio. Learn how to accelerate your DevOps using these resources, and efficiently build reliable, secure cloud native Java applications. See how to create, maintain, and deploy your Java apps across hybrid cloud environments, with an open-source stack that is tested, integrated, and supported worldwide by Oracle.

Functional Programming Idioms in Java

Many developers and organizations are immersed in Java's functional programming capabilities. Writing code is easy, but writing maintainable code takes effort, discipline, and care. What are some of the dos and don'ts we should keep in mind when programming in functional style? Spot the common mistakes you may have seen in your code base and learn several supporting pieces of evidence for why we should avoid these mistakes and how to write better quality functional style code.

How to Avoid Common Pitfalls with Modern Microservices Testing

Have you ever wondered why your microservices break in production after all the tests passed during continuous integration/continuous delivery (CI/CD)? Have you wondered if you're testing too much or too little? Learn about common pitfalls and how to catch them at build time rather than runtime. We share some common battle scars observed in the wild and introduce the testing pyramid—explaining how it allows you to continuously deploy microservices independently without fear. We demonstrate, through a test-driven development approach, how combining Pact contract testing with Quarkus developer joy can help prevent your microservices from breaking in production.

How to Run Your Application up to 60X Faster with Native Images

In a world with more and more distributed applications with no state control, performance is one of the biggest challenges (being related to startup or even to the response to the first request). For a while, this context made Java a dubious choice for approaches like serverless, microservices, and containers. Today we not only have platforms that take Java to a brand-new performance level; we also have something that allows us to take a step further: the native images built using GraalVM. Learn what can and can't be done with native images, and how you can run your code up to 60X faster today.

Jakarta EE 10: Simplicity for Modern and Lightweight Cloud Applications

Jakarta EE 10 is packed with new features that make it easy to develop modern, lightweight enterprise Java applications for the cloud. The new Jakarta EE Core Profile helps develop microservices with Jakarta EE technologies with runtimes smaller than ever. It even makes compiling Jakarta EE applications to native images possible—to reduce the footprint even further. We explore Jakarta EE 10's new features in an interactive way packed with live code demos. We also talk about what we can expect from the future of Jakarta EE.

Java and the Promise of Quantum Computing

We've all heard the hype: Quantum computers will leave our current machines wallowing in the dust. Quantum algorithms will crack our existing encryption schemes in seconds. Will it really happen? The answer depends on engineering problems that have yet to be solved. But for those who write code, many insights are already available. This lab lets you run Java code using Johan Vos's Strange platform. We use the code to learn about quantum computing's revolutionary approach to problem solving.

Java + Project Loom = Synchronous Performance

We long were forced to choose: either use complicated and performant reactive code, or use a simple (yet limited) synchronous approach. Thanks to Project Loom, the paradigm can shift once more—even for applications that require high concurrency. We introduce a server designed for Loom with fully synchronous routing that can block as needed, yet still provide high performance under heavy concurrent load. We then dive a bit deeper to show the advantages of Project Loom, design choices made, and the implementation of other protocols, such as HTTP/1.1, HTTP/2, gRPC, and WebSocket.

(Mis)Understanding Cloud Native Java

Cloud is great, and cloud native is really nice. However, some misconceptions and terms are often thrown around—from JDK distributions and memory footprints to startup times, health probes, observability, serverless Java apps, zero downtime, and many more. Some can be confusing, and some even intimidating. We try to bust a few myths about cloud native development and give you some pointers on how you can develop better and more modern applications.

New Java features: Simplified Design Patterns

Java is often accused of being too verbose. We show how new and announced features and syntactic improvements in Java are helping to reduce the truth of this. We examine how newly added features and semantic improvements contribute to our code's simplification, maintainability, and efficiency. Find out how to use these new features to solve everyday challenges. We show a beauty of pattern matching, Records, Sealed classes and more on commonly used design patterns.

Refactoring Rules: How and When to Refactor Java Code

Test-driven development (TDD) is a multistep process, but most developers skip the last step (refactoring) because they aren't confident in how to do it. The test is green, right? Isn't that what's supposed to happen on TDD? Not really... Thinking like this leads to a fragile pile of code that ends up causing more harm than good. This fast-paced, action-focused presentation shares refactoring guidelines you can quickly apply to any piece of code—letting you turn your first draft into a flexible and maintainable design. With a little practice, the refactoring step will be another fun part of the development cycle.

Supercharge Your Java Code for Optimal Database Performance

Java is lightning-fast and powerful but, when a database is part of the stack, application performance can quickly hit a bottleneck. For years, databases have been seen as the slow, monolithic backends that limit throughput. But are they the real culprits? Not necessarily. Most of the time, the code—using autocommit, too many network round-trips, and unnecessary work on the database end—is the issue. We show some of these pitfalls and how to avoid them using code refactoring and simple tricks to supercharge your application. Learn the fundamentals of database performance and never wait for a reply from your DBA again.

Training and Tracking Machine Learning Models in Java with Tribuo

Tribuo is a Java machine learning (ML) library, developed by Oracle Labs, used inside Oracle since 2017, and open sourced in 2020. It has several features that make it suitable for enterprise deployments of ML models. It can train and deploy ML models in Java and tracks the provenance of the models it trains. Each model is self-describing; it knows its training data, how that data was processed, and all the algorithmic details that went into building it. Tribuo also can export models in ONNX format and integrates with popular libraries like TensorFlow and XGBoost. Get introduced to Tribuo, learn how to use it for a variety of ML tasks, and watch as we demonstrate its integrated provenance features.

Your Guide to OpenJDK Development

Java, its libraries, and Java HotSpot VM are all built through OpenJDK, an open-source project. The OpenJDK Developers’ Guide aligns developers around terminology and process. Learn how you can contribute to the project.

The Future of Java Is You

Not only does Oracle take our Java leadership seriously, we also embrace our stewardship of the Java community. As the Java language and platform evolves to rapidly address modern application development, Oracle continues to invest in the Java community to ensure it remains one of the strongest developer ecosystems on the planet. In this keynote, learn about the many Java community programs from Oracle that give developers a voice in shaping the future of Java.

Source: oracle.com

Continue reading

Why does Java’s hashCode() in String use 31 as a multiplier?

How hashing is done?

Hashing

A hash works by allocating a value into one of the many storage spaces it has, allowing for fast retrieval later. This storage space is also known as buckets.

Hash identifies where to insert which data and that also hash tells in constant time in which bucket the value is stored.

Insert using hash

Problems with Hash:

Now though hashing has the benefit of fast retrieval of data items, it also has some disadvantages. It primarily has 2 problems associated with it

1. Values that are complex and difficult to compare:

◉ It is easy to solve this problem if you decompose complex values into a key or hash that is easy to work with. The easiest way to accomplish this is of course to generate unique numbers from your value. The number must be unique because we want to distinguish one value from another. Primes are a great tool for making numbers unique.

◉ Using primes in hashes allows us to ensure that a product of a prime with any other number has the best chance of being unique (not as unique as the prime itself, however).

◉ In order to generate a unique hash, you multiply each digit or letter in the string “Dev” with a prime number and add them up.

Nevertheless, prime hashing is an old technique. The key is to understand you can move on to other hashing systems as long as your key is sufficiently unique.

2. Sequential searches are not fast for large data sets:

◉ In this case, the sequential search would adversely affect hash performance, directly proportional to the number of values contained. Therefore, you would have a linear performance cost (O(n) ), which becomes progressively worse as the number of keys(n) increases.

◉ Additionally, if you are dealing with strings or other complex types, the number of checks or comparisons becomes prohibitively expensive.

What is the purpose of 31?

Let’s say your container is a fixed array of 16 items, so you have your unique identifier for each value now.

How do you assign this value to these buckets or containers? 

◉ Using the same location as the value or the generated unique number, known as the hash key is the easiest way to decide where to place the hash key.

◉ When you place your keys in the containers, you would receive a different key number and therefore a different distribution of the keys in your array depending on the prime you used in your array. 

◉ Therefore, the same key “DEV” would be D * 31 + E * 31 + V * 31  for prime 31 and it would generate a different key for the “DEV” with D * 30 + E* 30 + V * 30, so data would go into a different location based on the prime used because the key produced is different.

To avoid collision also:

It is possible that certain strings will generate the same key. In such cases, the individual hash storage can be converted into a link list or another type of storage that can store all the duplicate keys. This is why the bucket is called the individual hash storage. So to keep the minimum number of collisions we consider unique values.

Source: geeksforgeeks.org

Continue reading