Core Java Notes By Kv Rao Sir

0 views

Skip to first unread message

Analisa Wack

unread,

Aug 3, 2024, 4:31:34 PM8/3/24

to asglocatkber

The word Core describes the basic concept of something, and here, the phrase 'Core Java' defines the basic Java that covers the basic concept of Java programming language. We all are aware that Java is one of the well-known and widely used programming languages, and to begin with it, the beginner has to start the journey with Core Java and then towards the Advance Java. The Java programming language is a general-purpose programming language that is based on the OOPs concept. The ocean of Java is too deep to learn, i.e., as much you learn more, you will know its depth. Java is a platform-independent and robust programming language. The principle followed by Java is WORA that says Write Once, Run Anywhere. The programming language is quite simple and easy to understand. But one should know that Core Java is not different from Java. Java is complete in itself, but for the beginners, it is natural that the beginner must begin with the core concepts of Java. In actual, Java has different editions, where Core Java is one of the parts of an edition.

The Java SE is a computing-based platform and used for developing desktop or Window based applications. Thus, core Java is the part of Java SE where the developers develop desktop-based applications by using the basic concepts of Java where JDK (Java Development Kit) is a quite familiar Java SE implementation.

Also known as Java 2 Platform or J2EE. It is the enterprise platform where a developer develops applications on the servers, i.e., the enterprise development. This edition is used for web development.

Although these major concepts hold its own depth, after gaining and implementing the best knowledge in the basic Java concepts, one can move towards the advanced Java version as the advanced section of the Java is quite interesting but can only be understood when the core concepts of Java are clear.

Both Core Java and Advance Java are parts of Java programming, but for understanding the entire Java better, we need to differentiate between both. So, below we have described some differences between both core java and advance Java:

Annex 2: Anannotated API specification showing the exact differences between Java SE 20 and Java SE 21. Informative background for these changes may be found in the list of approved Change Specification Requests for this release.

Annex 3: Java SE 21 Editions ofThe Java Language Specification andThe Java Virtual Machine Specification. The Java SE 21 Editions contain all corrections and clarifications made since the Java SE 20 Editions, as well as additions for new features.

The descriptions on this Release Notes page also identify potential compatibility issues that you might encounter when migrating to JDK 21. The Kinds of Compatibility page on the OpenJDK wiki identifies the following three types of potential compatibility issues for Java programs that might be used in these release notes:

In effect, a scoped value is an implicit method parameter. It is "as if" every method in a sequence of calls has an additional, invisible, parameter. None of the methods declare this parameter and only the methods that have access to the scoped value object can access its value (the data). Scoped values make it possible to pass data securely from a caller to a faraway callee through a sequence of intermediate methods that do not declare a parameter for the data and have no access to the data.

Processes started by Runtime.exec and ProcessBuilder can be enabled to log the command, arguments, directory, stack trace, and process id. The exposure of this information should be reviewed before implementation. Logging of the information is enabled when the logging level of the System#getLogger(String) named java.lang.ProcessBuilder is System.Logger.Level.DEBUG or Logger.Level.TRACE. When enabled for Level.DEBUG, only the process id, directory, command, and stack trace are logged. When enabled for Level.TRACE, the command arguments are included with the process id, directory, command, and stack trace.

Calls to java.lang.System.exit() and Runtime.exit() are logged to the logger named java.lang.Runtime with a logging level of System.Logger.DEBUG. When the configuration of the logger allows, the caller can be identified from the stack trace included in the log.

The methods Math.clamp() and StrictMath.clamp() are added to conveniently clamp the numeric value between the specified minimum and maximum values. Four overloads are provided in both Math and StrictMath classes for int, long, float, and double types. A clamp(long value, int min, int max) overload can also be used to safely narrow a long value to int.

Two new methods indexOf(int ch, int beginIndex, int endIndex) and indexOf(String str, int beginIndex, int endIndex) are added to java.lang.String to support forward searches of character ch, and of String str, respectively, and limited to the specified range of indices.

Besides full control on the search range, they are safer to use than indexOf(int ch, int fromIndex) and indexOf(String str, int fromIndex), respectively, because they throw an exception on illegal search ranges.

Unlike the split() methods, these new splitWithDelimiters() methods in java.lang.String and java.util.regex.Pattern return an alternation of strings and matching delimiters, rather than just the strings.

The instances returned by HttpClient.newHttpClient(), and the instances built from HttpClient.newBuilder(), provide a best effort implementation for these methods. They allow the reclamation of resources allocated by the HttpClient early, without waiting for its garbage collection.

Note that an HttpClient instance typically manages its own pools of connections, which it may then reuse when necessary. Connection pools are typically not shared between HttpClient instances. Creating a new client for each operation, though possible, will usually prevent reusing such connections.

China National Standard body (CESI) has recently published GB18030-2022 which is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The Charset implementation for this new standard has now replaced the prior 2000 standard. However, this new standard has some incompatible changes from the prior implementation. For those who need to use the old mappings, a new system property jdk.charset.GB18030 is introduced. By setting its value to 2000, the previous JDK releases' mappings for the GB18030 Charset are used which are based on the 2000 standard.

The methods public StringBuilder repeat(int codePoint, int count) and public StringBuilder repeat(CharSequence cs, int count) have been added to java.lang.StringBuilder and java.lang.StringBuffer to simplify the appending of multiple copies of characters or strings. For example, sb.repeat('-', 80) will insert 80 hyphens into the value of the java.lang.StringBuilder sb object.

Emoji-related properties introduced in (JDK-8303018) can now be used as binary properties in the java.util.regex.Pattern class. One can match characters that have Emoji-related properties with the new \pIsXXX constructs. For example,

The Sequenced Collection API introduces several new interfaces into the collections framework, providing enhancements to many existing collections classes. The new API facilitates access to elements at each end of a sequenced collection, and provides the ability to view and iterate such collections in reverse order. See JEP 431 for additional information.

The introduction of new collections interfaces, along with default methods, introduces some compatibility risk, including the possibility of both source and binary incompatibilities. The introduction of default methods in an interface hierarchy may cause conflicts with methods declared on existing classes or interfaces that extend collections interfaces - this could result in either source or binary incompatibilities. The introduction of new interfaces also introduces new types into the system, which can change the results of type inference, leading in turn to source incompatibilities.

The Java Virtual Machine (JVM) now prints a warning to standard error when a JVM Tool Interface (JVM TI) agent or Java Agent is dynamically loaded into a running JVM. The warning is intended to prepare for a future release that disallows, by default, dynamic loading of agent code into a running JVM.

Agents are programs that run in the JVM process and make use of powerful JVM TI or java.lang.instrument APIs. These APIs are designed to support tooling such as profilers and debuggers. Agents are started via a command line option, for example -agentlib or -javaagent, or they can be started into a running VM using the JDK specific com.sun.tools.attach API or the jcmd command. Agents loaded into a running VM will now print a warning. There is no warning for agents that are loaded at startup via command line options.

The HotSpot VM option EnableDynamicAgentLoading controls dynamic loading of agents. This option has existed since JDK 9. The default, since JDK 9, is to allow dynamic loading of agents. Running with -XX:+EnableDynamicAgentLoading on the command line serves as an explicit "opt-in" that allows agent code to be loaded into a running VM and thus suppresses the warning. Running with -XX:-EnableDynamicAgentLoading disallows agent code from being loaded into a running VM and can be used to test possible future behavior.

In addition, the system property jdk.instrument.traceUsage can be used to trace uses of the java.lang.instrument API. Running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true causes usages of the API to print a trace message and stack trace. This can be used to identify agents that are dynamically loaded instead of being started on the command line with -javaagent.

A full garbage collection (GC) in the Garbage First (G1) collector now moves humongous objects to avoid Out-Of-Memory situations due to a lack of contiguous space in the Java heap when the application allocates humongous objects.