JDK 17

All

Red Hat will launch OpenJDK 17 production ready at the end of this year. And there are several features which include the following:

  1. Switch expressions
  2. Text blocks
  3. Pattern matching of instanceof
  4. Records
  5. Restricting float pointing operating
  6. Hidden classes
  7. Foreign function & Memory API
  8. ZGC Prod ready ~ https://openjdk.java.net/jeps/377

I’ll be doing some blog posts about the features above.

Also, in terms of overhead, the heap/native size overhead will get smaller because of the Elastic Metaspace, instead of a static. That is very interesting and certainly, I will do some benchmarks to see the comparison.

There was much stuff removal/deprecated as well, like CMS, Nashorn, RMI activation.

It is important to highlight here that ZGC, the ultra fast GC from Oracle – similar to Shenandoah in terms of speed – is now production ready as well, I think I already did one or two blog posts about it. Shenandoah is production ready in JDK 8 and JDK 11, since it was back-ported to JDK 8.

ZGC

All

Previously I have done some posts about Shenandoah, and now it is time to talk about Oracle’s ZGC.

ZGC has an algorithm similar to Shenandoah (in terms of concurrence GC) only it uses coloured pointers to mark the objects, and that demands 64bits, so it doesn’t have 32bits of ZGC, necessary for the reference colouring. In comparison to Shenandoah’s additional one level of abstraction (forwarding pointer) that adds one words (+the other two already in OpenJDK). The tradeoff used to be the footprint, because for each object you add one more word (warning: this is true for Shenandoah1, in Shenandoah2, it uses the mark word for the forwarding pointer, so then there is no more footprint). Of course, Shenandoah it aims for very small pauses, i.e. sub-millisecond, handle of high heap and scalable pauses. It is available for JDK 11 on Windows, Linux 64, macOS and Linux/Aarch architectures.

This is a big thing is the tradeoff Oracle’s ZGC took his 64 bit implementation, so no 32bits. I don’t think ZGC has a degradation mode (or pacing mechanism) as Shenandoah does have, meaning it will not stall the threads of the application to make the GC finish the job (it will add latency as consequence, although invisible – 42:00).

Like G1GC, and much of contrary to CMS, it does not have that many flags to set as well. As Shenandoah you can play/tune it a bit, with basic initial heap size, number of concurrent GC threads, NUMA – JDK 17 feature – Huge and large pages. On some versions one can set AlwaysPreTouch.

Arquillian testing

All

Arquillian testing framework helps considerably doing a simple Wildfly/EAP test.

Reasons to be very easy:
1. It is pretty simple to write a test, as any unit test should be and it allows to package the application in one function pretty smothly:

    @Deployment
    public static WebArchive createDeployment()
    {
        System.out.println("create Deployment");

        WebArchive archive = ShrinkWrap.create(WebArchive.class, "sample.war")
                .addPackage("com.example")
                .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml")
                .addAsResource("validation.xml", "META-INF/validation.xml");

        System.out.println(archive.toString(true));

        archive.as(ZipExporter.class).exportTo(new File("/tmp/" + archive.getName()), true);

        return archive;
    }

2. Using arquilllian.xml enables to select a certain specific container to be deployed, as little as the lines below to select the container:

  </container>
  <container qualifier="arquillian-wildfly-managed">
    <configuration>
      <property name="chameleonTarget">${chameleon.target}</property>
      <property name="serverConfig">standalone-full.xml</property>
    </configuration>
  </container>

3. Testing is pretty straightforward

    @Test
    public void Test1() throws Exception
    {
        System.out.println("Calling URI: " + serviceUri.toString()); //to show the url being called

        final String targetUrl = serviceUri.toString() + "hello";
        log.info("The target URL is: {}", targetUrl);
        ResteasyClient client = new ResteasyClientBuilder().build();
        ResteasyWebTarget target = client.target(targetUrl);
        ValidatedJaxRsInterface validatedJaxRs = target.proxy(ValidateJaxRsInt.class);
        try
        {
            log.info("Testing");
            log.info("Validated call responded with: {}", validation.Hello());
        }
        catch (Exception exception)
        {
            log.error("Got an error when calling the validated endpoint: {}", exception.getMessage(),exception);
            if (exception instanceof BadRequestException)
            {
                BadRequestException exp = (BadRequestException) exception;
                log.error("The response was bad request :/ {}", exp.getMessage());
            }
        }
        log.info("Calling validation.Hello");
    }

4. One can use chameleon or wildfly arquillian straight on the pom to get the container, like below:

    <configuration>
      <forkCount>1</forkCount>
      <redirectTestOutputToFile>false</redirectTestOutputToFile>
      <systemPropertyVariables>
        <arquillian.launch>arquillian-wildfly-${container.type}</arquillian.launch>
        <chameleon.target>jboss eap:${jboss.version}:${container.type}</chameleon.target>
      </systemPropertyVariables>
    </configuration>

Depending on the EAP version one should use the wildfly arquillian container image instead, see difference below:

<!-- Arquillian Chameleon -->
    <dependency>
      <groupId>org.arquillian.universe</groupId>
      <artifactId>arquillian-chameleon</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency> 


<!--- wildfly-arquillian-container-managed -->
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>

5. Adding validation becomes almost trivial with the validation.xml file:

   <executable-validation enabled="true">
    <default-validated-executable-types>
      <executable-type>CONSTRUCTORS</executable-type>
      <executable-type>NON_GETTER_METHODS</executable-type>
    </default-validated-executable-types>
  </executable-validation>

taglib in jsp

All

On JSP, yes JSP, the taglib directive declares that your JSP page uses a set of custom tags, the usage of JSTL can be quick straightforward:

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>  

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Hello from JSP</title>
</head>
<body>
${label} <br>

<c:out value="Example taglib" /> <!-- the c is the tag lib using the core jstl core taglib -->
	
	<c:out value="Let's output this" />
	<c:set var="dummyName" scope="session" value="2000"/>
	<c:out value = "${dummyName}" />
	
	<c:if test="${dummyName!=null}">
		No estoy embarasada!
	</c:if>
		
	<a href = "<c:url value = "https://www.youtube.com/watch?v=68-2C9L5dJM"/>">URL test</a>
	
	<c:forEach var="headerValue" items="${header}">
		${headerValue.key},${headerValue.value}<BR />
	</c:forEach>
</body>
</html>

Tutorials

For a complete tutorial, my favourite references are TutorialsPoint and W3 Processing, for sure. Seeing what is useful for you project. It is interesting that one Eclipse/Netbeans just click Dynamic Web Project striaght way, no need for web.xml file as before.

JSP is appropriate for fast prototyping and easily deployment. Of course this technology is being deprecated for Django/Python, which I already had made some posts here, but will do more eventually.

StringBuilder, StringBuffer and JVM flags for Strings

All

When dealing with Strings, which are of course immutable objects in Java, it may be easier to use a StringBuilder or StringBuffer implementation – as suggested by Geekforgeeks

StringBuffer vs StringBuilder

StringBuffer has a slight better performance than StringBuilder and is able to deal with multiple thread accessing. But is good to know it is there.

 StringBuilder stringBuilderExample = new StringBuilder("Example");
 stringBuilderExample.append("of String Builder");

 StringBuffer stringBuffer = new StringBuffer("Example");
 stringBuffer.append(" of String Buffer");

But factually, comparing both of them in a small benchmark, the performance is the same pretty much, but for a small benchmark, stringBuffer uses a little bit less memory.

real	0m0.048s <----------------------------- 0.048s (from 0.035s up to 0.055s)
user	0m0.044s
sys	0m0.009s

String JVM flags

There are some JVM flags that come in hand when dealing with strings as well:

JVM flagResult
UseStringCache
UseCompressedStrings
OptimizeStringConcat

Special thanks

Special thanks to Francesco Marchioni and his amazing blog, the very famous mastertheboss blog. I’m his fan and pretty much have his whole collection of books on my table, DataGrid, Quarkus, EAP, JBoss.

Quick start mbean

All

Client Mbean

Using a JMX client one can connect to a container Server MBeans and get information very easily. On this blog I have wrote about Jconsole and JvisualVM.

My colleague, Alexander Barbosa, wrote this nice Tutorial to get info on Heap using Mbean. Basically the information comes from the `java.lang:type=Memory`. To get heap or non-heap memory.

	ObjectName memoryMXBean = new ObjectName("java.lang:type=Memory");

You may need to add the credentials for connection and using a map this can be done quick straightforward:

		credentials[0] = "admin";
		credentials[1] = "admin";
		map.put(JMXConnector.CREDENTIALS, credentials);

		// passing server credentials
        JMXConnector jmxConnector = JMXConnectorFactory.connect(serviceURL, map);

Silly mistakes to avoid:

Congratulations you forgot the `.java` part – there is nothing my sully than that:

$ javac -classpath .:$$JBOSS_HOME/bin/client/jboss-client.jar jmxTesterror: 
Class names, 'jmxTest', are only accepted if annotation processing is explicitly requested
1 error

Xms

All

Xms specifies the initial memory allocation. Xmx sets the maximum memory allocation.

For a regional collector, like G1GC or Shenandoah, the pre-allocate the memory because they divide the heap in sections.

On the other hand, the ParallelGC, which is a generational collector – will divide the heap in generations: young, survivor, tenure generation.

But interestingly, ParallelGC will not pre-allocate the memory and as consequence one could cheat the memory and set a Xmx and Xms higher than the memory available in the box, on the example below it has only 2Gb available:

#grep MemTotal /proc/meminfo
MemTotal:        2000000 kB <-------- 2Gb
$JAVA_HOME/bin/java -Xmx20G -Xms2520m -Dfoo=example -XX:+PrintFlagsFinal GetValue <--- just prints string: Running Example
Running example

In contrast to G1/Shenandoah, which will pre-allocate/allocated at the start directly and it will crash right away:

$JAVA_HOME/bin/java -XX:+ShenandoahLogDebug -Xmx20G -Xms1700m -XX:+UseG1GC -Dfoo=example GetValue
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000002c0000000, 1782579200, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 1782579200 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /root/test_openjdk8_shenandoah_bug/test_application/hs_err_pid28074.log <------------------------------------------------------ crash log with insufficient memory
$JAVA_HOME/bin/java -XX:+ShenandoahLogDebug -Xmx20G -Xms1600m -XX:+UseG1GC -Dfoo=example GetValue
Running Application <------------------------------------------------------------------------------------------------------------ using Xms as 1.6Gb maximum

But of course, eventually setting a higher xms/xmx than the max memory available on the box it will crash, even if it is not pre-allocated/allocated in the start of the JVM.

-Xcheck:jni

All

The usage of this JVM flag is for as memory checks or checks on JNI functions.

This flag sometimes, depending on the function, it shows many warnings.

Check:jni, helps to debug applications that use the Java Native Interface (JNI).

java -Xcheck:jni -verbose:jni TestJNI
 execve("/jdk-11.0.1/bin/java", ["/jdk-11."…, "-Xcheck:jni", "-verbose:jni", "TestJNI"], 0x7ffd7b68e388 /* 72 vars */) = 0
 brk(NULL)                               = 0xb48000
 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fda7bdff000
 readlink("/proc/self/exe", "/jdk-11."…, 4096) = 44
 access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
 open("/jdk-11.0.1/bin/../lib/jli/tls/x86_64/libz.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 stat("/jdk-11.0.1/bin/../lib/jli/tls/x86_64", 0x7fff832f29b0) = -1 ENOENT (No such file or directory)
 open("/jdk-11.0.1/bin/../lib/jli/tls/libz.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 stat("/jdk-11.0.1/bin/../lib/jli/tls", 0x7fff832f29b0) = -1 ENOENT (No such file or directory)
 open("/jdk-11.0.1/bin/../lib/jli/x86_64/libz.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 stat("/jdk-11.0.1/bin/../lib/jli/x86_64", 0x7fff832f29b0) = -1 ENOENT (No such file or directory)
 open("/jdk-11.0.1/bin/../lib/jli/libz.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 stat("/jdk-11.0.1/bin/../lib/jli", {st_mode=S_IFDIR|0775, st_size=1024, …}) = 0
 open("/jdk-11.0.1/bin/../lib/tls/x86_64/libz.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

And of course the check part:

mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fda7bcdc000
 clone(child_stack=0x7fda7bddbfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fda7bddc9d0, tls=0x7fda7bddc700, child_tidptr=0x7fda7bddc9d0) = 3660
 futex(0x7fda7bddc9d0, FUTEX_WAIT, 3660, NULLChecked JNI functions are being used to validate JNI usage
 [Dynamic-linking native method java.lang.Object.registerNatives … JNI]
 [Registering JNI native method java.lang.Object.hashCode]
 [Registering JNI native method java.lang.Object.wait]
 [Registering JNI native method java.lang.Object.notify]
 [Registering JNI native method java.lang.Object.notifyAll]
 [Registering JNI native method java.lang.Object.clone]
 [Dynamic-linking native method java.lang.System.registerNatives … JNI]
 [Registering JNI native method java.lang.System.currentTimeMillis]
 [Registering JNI native method java.lang.System.nanoTime]
 [Registering JNI native method java.lang.System.arraycopy]
 [Dynamic-linking native method java.lang.Class.registerNatives … JNI]
 [Registering JNI native method java.lang.Class.getName0]