This demo illustrates how to capture telemetry data with OpenTelemetry between distributed services and view interactions between microservices in a system.

Remember mainframes? Serverless is pretty much that: we own the machine and you rent out time on our big iron. We went full circle on progress!

Ever looked for a comprehensive tutorial to Hibernate and JPA that is fun and entertaining at the same time? Look no further than this video tutorial.

As we continue the journey into Java bytecode, here, in part two of the series, delve a bit deeper into ConstantPool.

Interestingly, we don’t even need the whole set of bytecode in Java. Today we use around 205. These are called operation codes or simply "opcodes."

This article outlines the difficulties in extracting plain text from regular PDF documents at scale and demonstrates two API solutions that efficiently perform that task.

One of the most popular starters in Spring Boot applications is Spring Data JPA. Hence, you have nearly no chance to avoid JPA-related questions during a job interview. Let's take a look at the most frequently asked questions with detailed answers.

In this post, continue the journey to create a geo-distributed messenger in Java by looking at several connectivity options for Heroku and YugabyteDB Managed.

Confronted with an interesting java.lang.OutOfMemoryError: Metaspace problem in a microservice application? Learn the steps taken to troubleshoot the problem.

Looking at the popularity, PHP has been used by 81.25 percent of the tech companies worldwide just to build their web applications.

SPL (JVM-based programming language) can parse structured data files of regular-or irregular-format, represent 2D/hierarchical data in a uniform way, and more.

This article shows how to use a strategy pattern with a pinch of enums and functional syntactic sugar in functional Java.

This tutorial guides you to create a custom connector for Mule 4 which includes both Source and Operation components.

Let's explore ten Java programming features used frequently by developers in their day-to-day programming jobs.

Code has cosmetic and intrinsic characteristics. See examples demonstrating how to achieve the same intrinsic with different cosmetics and vice versa.

Welcome to my journal documenting my experience building a geo-distributed app in Java from scratch. Here, I’ll share my first results and any challenges.

Thoughts on pattern matching, records, and sealing.

Last year we saw the launch of a new Web programming language Dart - Structured Web Programming from Google. A very interesting approach to support web application development. Not so long after Go, Groovy, Ruby, Scala, << Name your DSL here >>; we see Dart. Is it a good thing to have at least one programming language to solve one problem? The answer is, like we already know, it depends. Stay Away From “Do it Yourself” It is your choice as to if you will try to do things yourself or allow the truly seasoned professionals to help out. Some decide that they are going to try to go it alone when they are programming something new, but this often ends up in a less than desirable place. It may even be more expensive than just hiring an expert who can help you get it programmed for you in the first place. Most people do not go it alone with the vast majority of important services in their life, so why should they ever attempt to do so when they are looking at how to create a website? It is best to avoid making this mistake, and just try to make some progress towards your goals by hiring people who truly know how to help you make the progress that you need to make. Some important backgrounds you should know about the multi-programming language paradigm are the following: 1. You can read Martin Fowler's article about language-oriented programming with language workbenches which enables you to write small programming languages easily. In this article I see everyone writing their small language, everywhere. In this concept, we see DSL (Domain Specific Language) as the future of our programming activities. Source: http://martinfowler.com/articles/languageWorkbench.html 2. Neal Ford talked about Polyglot Programming, combining multiple programming languages in application development. Later Mr. Fowler added this paradigm with Polyglot Persistence, using different types of databases within one application. Source: http://memeagora.blogspot.com/2006/12/polyglot-programming.html and http://martinfowler.com/bliki/PolyglotPersistence.html Since 2006 I already discussed and collected some experiences in multi programming language paradigm: 1. I remember a “hot” discussion in 2006 with Sebastian Meyen, chief editor of JavaMagazin Germany, also the biggest organizor of Java Conference JAX. We agreed to see the future of programming in a multi-language paradigm concept. I also said that all those languages will be based on Java VM. I also told him that one day SAP will move ABAP as a language that can be run within the Java VM, so just another language within the Java environment, with no two different personalities anymore. Today we see the beginning of this in the project called Caffeine ABAP. Source: https://cw.sdn.sap.com/cw/groups/caffeine 2. Also in 2006 I had a project in which we also used different kinds of languages and also created our own DSL: Java for the most implementation stuff UML for the design of the business objects. We generate a lot of things using the concept of MDA (Model Driven Architecture) Groovy for a lot of things, especially for writing unit tests Based on ANTLR we create our own DSL for some aspects of the application It was really exciting and we had some very good programmers in the project. The result was a very nice and flexible product, just as what we expected at the beginning of the project. Please read this article in the German language for more information: http://www.sigs.de/publications/os/2009/02/dewanto_egger_OS_02_09.pdf So after all those nice things about the multi-language paradigm, I told you, why does this suck at the end? Here are some reasons from my point of view: 1. As typical in application development the problem comes first in the maintenance phase after all the capable programmers leave the project. Did you, programming language creators ever try to teach a new programming language to a “normal”, 9 till 5 programmers? I’m not talking about 9 (am) till 9 (pm) programmers who love to learn new languages. It is definitely tough to be proficient in one programming language. This is comparable with the languages we speak every day. I’m not a native English speaker, so I’m quite sure that I made a lot of syntax and grammar errors in this article. It is possible to be able to speak three or four languages perfectly but this is an exception. 2. Did you ever try to maintain a big Struts web application with AJAX? Just try to add functionality and you will end up creating and editing a lot of files: Action and Form files, Struts XML configuration files, JavaScript files with JSON, and also HTML or JSP files. Can you imagine adding Groovy, Scala, and Dart additionally into that web app? The complexity of such a project is very high. 3. Creating a new programming language means that you also have to build the environment for it. Good IDE, good documentation, good community support, a clear roadmap, and backward compatibility are some points to be done. Groovy is a bad example of this. In the early version of this language, the editor for Eclipse was really bad. After a while, they improved the editor but they made a lot of basic changes in the language so your old groovy applications do not work anymore. You are punished if you update to the new version. This never happens to Java. You still can compile Java 1.1 applications with Java 6 compiler. 4. Before you are creating your own DSL with e.g. ANTLR ask those language Gurus first, how hard it is to maintain a programming language for the long term. Before you discuss with them don’t ever create your own DSL. Especially if you are working for SME (Small and Medium-sized Enterprise). With a small team and small budget, you will never ever maintain your own language decently. So in year 2012, six years after my support to Polyglot Programming, I hope to see following things happen: 1. One language for all aspects in one application is the best concept ever. I name this as “One for All Programming Language paradigm”. Just like we don’t use English as a technical language, German as a literate language, and Indonesian as a community language, to be able to communicate internationally with each other we just use English pragmatically for all aspects of our life. In Germany, you need to speak German in all aspects to be able to communicate with others. My best solution so far is Java + XML, that’s it, no more, no less. No mixing with Groovy, Dart, Ruby, Scala, <> in one application. Especially if you are working as a contractor, please don’t try to use all those languages just for a small Java web application. I don’t say that you should not use the other languages at all. The only thing which is important is not to mix those languages in one application. In SME you may also want to use just one programming language for all your applications. 2. Concept like GWT (Java to JavaScript compiler) or XMLC (XML compiler which compiles XML, HTML to Java classes) is great. You can work just in plain Java. Guice with all Java and no XML is also a great solution (I know that SpringFramework is also doing this with Annotations). Android is great because it uses Java as its application programming language. In conclusion, I can only hope to see more such pure and plain Java solutions in 2012!

Nowadays Quarkus is known as Supersonic Subatomic Java. It provides a lot of features to facilitate build and deployment.

Java serialization is convenient to store the state of Java objects. However, there are some drawbacks of serialized data: It is not human-readable. It is Java-specific and is not exchangeable with other programming languages. It is not migratable if fields of the associated Java class have been changed. These drawbacks make Java serialization not a practical approach to storing object states for real-world projects. In a product developed recently, we use XStream to serialize/deserialize Java objects, which solves the first and second problems. The third problem is addressed with XMT, an open source tool developed by us to migrate XStream serialized XMLs. This article introduces this tool with some examples. Computer Languages Need to be Simplified So many of the issues that we all run into when we are working on converting computer languages into something that can be better understood by human beings is the fact that computer languages need to be simplified if possible. These languages are great for the computers that speak back and forth with one another, but they don’t necessarily work out as well when humans try to become involved with them. Many humans end up confused and unable to make much progress at all on getting these systems cleared up. Thus, it is necessary to get them cleaned up and made more usable. There are people who are actively working on this problem right now, but in the meantime, we may simply have to deal with computers that can’t do everything we would like for them to do. XStream deserialization problem when class is evolved Assume a Task class below with a prioritized field indicating whether it is a prioritized task: package example; public class Task { public boolean prioritized; } With XStream, we can serialize objects of this class to XML like below: import com.thoughtworks.xstream.XStream; public class Test { public static void main(String args[]) { Task task = new Task(); task.prioritized = true; String xml = new XStream().toXML(task); saveXMLToFileOrDatabase(xml); } private static void saveXMLToFileOrDatabase(String xml) { // save XML to file or database here } } The resulting XML will be: true And you can deserialize the XML to get back task object: import com.thoughtworks.xstream.XStream; import com.thoughtworks.xstream.io.xml.DomDriver; public class Test { public static void main(String args[]) { String xml = readXMLFromFileOrDatabase(); Task task = (Task) new XStream(new DomDriver()).fromXML(xml); } private static String readXMLFromFileOrDatabase() { // read XML from file or database here } } Everything is fine. Now we find that a prioritized flag is not enough, so we enhance the Task class to be able to distinguish between high priority, medium priority and low priority: package example; public class Task { enum Priority {HIGH, MEDIUM, LOW} public Priority priority; } However, deserialization of previously saved XML is no longer possible since the new Task class is not compatible with the previous version. How does XMT Address the Problem XMT comes to the rescue: it introduces the class VersionedDocument to version serialized XMLs and handles the migration. With XMT, serialization of task object can be written as: package example; import com.pmease.commons.xmt.VersionedDocument; public class Test { public static void main(String args[]) { Task task = new Task(); task.prioritized = true; String xml = VersionedDocument.fromBean(task).toXML(); saveXMLToFileOrDatabase(xml); } private static void saveXMLToFileOrDatabase(String xml) { // save XML to file or database here } } For task class of the old version, the resulting XML will be: true Compared with the XML generated previously with XStream, an additional attribute version is added to the root element indicating the version of the XML. The value is set to "0" unless there are migration methods defined in the class as we will introduce below. When Task class is evolved to use enum based priority field, we add a migrated method like the below: package example; import java.util.Stack; import org.dom4j.Element; import com.pmease.commons.xmt.VersionedDocument; public class Task { enum Priority {HIGH, MEDIUM, LOW} public Priority priority; @SuppressWarnings("unused") private void migrate1(VersionedDocument dom, Stack versions) { Element element = dom.getRootElement().element("prioritized"); element.setName("priority"); if (element.getText().equals("true")) element.setText("HIGH"); else element.setText("LOW"); } } Migration methods need to be declared as a private method with the name in the form of "migrateXXX", where "XXX" is a number indicating the current version of the class. Here method "migrate1" indicates that the current version of the Task class is of "1", and the method migrates the XML from version "0" to "1". The XML to be migrated is passed as a VersionedDocument object which implements the dom4j Document interface and you may use dom4j to migrate it to be compatible with the current version of the class. In this migration method, we read back the "prioritized" element of version "0", rename it as "priority", and set the value as "HIGH" if the task is originally a prioritized task; otherwise, set the value as "LOW". With this migration method defined, you can now safely deserialize the task object from XML: package example; import com.pmease.commons.xmt.VersionedDocument; public class Test { public static void main(String args[]) { String xml = readXMLFromFileOrDatabase(); Task task = (Task) VersionedDocument.fromXML(xml).toBean(); } private static String readXMLFromFileOrDatabase() { // read XML from file or database here } } The deserialization works not only for XML of the old version but also for XML of the new version. At deserialization time, XMT compares the version of the XML (recorded in the version attribute as we mentioned earlier) with the current version of the class (maximum suffix number of various migrate methods), and runs applicable migrate methods one by one. In this case, if an XML of version "0" is read, method migrate1 will be called; if an XML of version "1" is read, no migration methods will be called since it is already up to date. As the class keeps evolving, more migration methods can be added to the class by increasing the suffix number of the latest migration method. For example, let's further enhance our Task class so that the priority field is taking a numeric value ranging from "1" to "10". We add another migrate method to the Task class to embrace the change: @SuppressWarnings("unused") private void migrate2(VersionedDocument dom, Stack versions) { Element element = dom.getRootElement().element("priority"); if (element.getText().equals("HIGH")) element.setText("10"); else if (element.getText().equals("MEDIUM")) element.setText("5"); else element.setText("1"); } This method only handles the migration from version "1" to version "2", and we do not need to care about version "0" anymore, since the XML of version "0" will first be migrated to version "1" by calling the method migrate1 before running this method. With this change, you will be able to deserialize the task object from XML of the current version and any previous versions. This article demonstrates the idea of how to migrate field change of classes. XMT can handle many complicated scenarios, such as migrating data defined in multiple tiers of class hierarchy, addressing class hierarchy change, etc. For more information of XMT, please visit http://wiki.pmease.com/display/xmt/Documentation+Home