Articles

I have lost count of the number of times I have been told that Java is not a suitable language in which to develop applications where performance is a major consideration. My first response is usually to ask for clarification on what is actually meant by “performance” as two of the most common measures – throughput and latency, sometimes conflict with each other, and approaches to optimise for one may have a detrimental effect on the other. 

Techniques exist for developing Java applications that match, or even exceed, the performance requirements of applications that have been built using languages more traditionally used for this purpose. However, even this may not be enough to get the best performance from a latency perspective. Java applications still have to rely on the Operating System to provide access to the underlying hardware. Typically latency-sensitive (often called “Real Time”) applications operate best when there is almost direct access to the underlying hardware, and the same applies to Java. In this article, we will introduce some approaches that can be taken when we want to have our applications utilise system resources most effectively. 

Source de l’article sur DZONE

java.lang.String#intern() is an interesting function in Java. When used in the right place, it has the potential to reduce the overall memory consumption of your application by eliminating duplicate strings in your application. To learn how the intern() function works, you may refer to this blog. In this post let’s discuss the performance impact of using java.lang.String#intern() function in your application.

Intern() Function Demo

To study the performance behaviour of the intern() method, we created these two simple programs:

Source de l’article sur DZONE

Have you ever wanted to know how text editors work, or how shell scripts change terminal text colors, update lines without scrolling, or move the cursor around? Surprise, surprise: even as Java devs, we can do this! 

In this series, I’ll walk you through building a terminal-based text editor with Java

Source de l’article sur DZONE

Ahoy, matey! I’m back from a short vacation and ready to continue my pet project: geo-distributed messenger in Java! 

If you’re interested in how my dev journey began (and is going), check out the previous articles in this series:

Source de l’article sur DZONE

Continuing from part 2, let’s start this article with a bit of context first (and if you don’t like reading text, you can skip this introduction, and go directly to the section below where I discuss pieces of code).

Context

  • When we start an application program, the operating system creates a process.
  • Each process has a unique id (we call it a PID) and a memory boundary.
  • A process allocates its required memory from the main memory, and it manipulates data within a boundary.
  • No other process can access the allocated memory that is already acquired by a process.
  • It works like a sandbox, and in that way, avoids processes stepping on one another’s feet.
  • Ideally, we can have many small processes to run multiple things simultaneously on our computers and let the operating system’s scheduler schedule them as it sees fit.
  • In fact, this is how it was done before the development of threads. However, when we want to do large pieces of work, breaking them into smaller pieces, we need to accumulate them once they are finished.
  • And not all tiny pieces can be independent, some of them must rely on each other, so we need to share information amongst them.
  • To do that, we use inter-process communication. The problem with this idea is that having too many processes on a computer and then communicating with each other isn’t cheap. And precisely that is where the notion of threads comes into the picture.

The idea of the thread is that a process can have many tiny processes within itself. These small processes can share the memory space that a process acquires. These little processes are called « threads. » So the bottom line is that threads are independent execution environments in the CPU and share the same memory space. That allows them faster memory access and better performance.

Source de l’article sur DZONE

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.

Source de l’article sur DZONE

The Jersey project is very well documented so it makes it easy to learn REST with Java. In this article I’m going to build two projects. The first project will be a very simple HTML page that presents a form to the user and then submits it to a REST project residing on the same server. The second project will be the REST part.

For this article I used the following tools:
1. Netbeans 7
2. Apache Tomcat 7
3. Jersey
4. Java

Source de l’article sur DZONE

Two of the most popular message brokers used today are Kafka and those based around JMS. JMS is a long-standing Java API used generally for developing messaging applications, with its primary function of being able to send messages between two or more clients. Kafka, on the other hand, is a distributed streaming platform that provides a lot of scalabilities and is useful for real-time data processing. 

While both offer their own advantages and are highly useful in their own right, which of the two should you be actually using?

Source de l’article sur DZONE

In part 1, we introduced Instancio and how it can be used to automate data setup in unit tests. To recap, Instancio is a library that automates data setup in unit tests, with the goal of reducing manual data setup. More specifically, it accepts a class (or a « type token ») as an argument and returns a fully-populated instance of the class. Sticking to our Person class for all our examples, this can be done as follows:

Java

 

Person person = Instancio.create(Person.class); Map<UUID, Person> person = Instancio.create(new TypeToken<Map<UUID, Person>>() {});

Source de l’article sur DZONE

There are a good number of articles that articulate functional differences between HashMap, Hashtable, and ConcurrentHashMap. This post compares the performance behavior of these data structures through practical examples. If you don’t have the patience to read the entire post, here is the bottom line: when you are confronted with the decision of whether to use HashMap, Hashtable, or ConcurrentHashMap, consider using ConcurrentHashMap since it’s thread-safe implementation without compromise in performance.

Performance Study

 To study the performance characteristics, I have put together this sample program:

Source de l’article sur DZONE