Feed aggregator

Enum: Using the Name() and toString() Methods Correctly

Javalobby Syndicated Feed - Thu, 21-Sep-17 13:01

The Java Enum has two methods that retrieve that value of an enum constant, name() and toString(). The toString() method calls the name() method, which returns the string representation of the enum constant. In listing 1, the value returned by calling the name() and toString() on an Animal.DOG constant method is DOG.

Listing 1: Animal Enum:

Categories: Java

Java Command-Line Interfaces (Part 14): google-options

Javalobby Syndicated Feed - Thu, 21-Sep-17 09:01

The GitHub page for google-options states that google-options is a "command line argument parsing library from the folks at Google (Java)." The page goes on to say, "This is the command-line arguments parser from the Bazel Project. The com.google.devtools.common.options package has been split out into a separate jar for general utility." This blog post demonstrates applying google-options to processing command line options from Java code.

The example used in this post to demonstrate google-options is similar to the examples used in the earlier thirteen posts in this series on processing command line options in Java. This example supports two options: a required file path/name option expecting a String argument with that path and name and a verbosity option with no argument (its existence enables verbosity). Only the most relevant portions of the code will be shown in this post, but the full code is available on GitHub.

Categories: Java

Testing Time-Based Reactor Core Streams With Virtual Time

Javalobby Syndicated Feed - Thu, 21-Sep-17 03:01

Reactor Core implements the Reactive Streams specification and deals with handling a (potentially unlimited) stream of data. If it interests you, do check out the excellent documentation it offers. Here I am assuming some basic familiarity with the Reactor Core libraries Flux and Mono types and will cover how Reactor Core provides an abstraction to time itself to enable the testing of functions that depend on passage of time.

For certain operators of Reactor Core, time is an important consideration — for example, a variation of an "interval" function that emits an increasing number every 5 seconds after an initial "delay" of 10 seconds:

Categories: Java

Creating a REST Web Service With Java and Spring (Part 1)

Javalobby Syndicated Feed - Thu, 21-Sep-17 02:01

In the modern world of interconnected software, web applications have become an indispensable asset. Foremost among these web applications is the Representational State Transfer (REST) web service, with Java becoming one of the most popular implementation languages. Within the Java REST ecosystem, there are two popular contenders: Java Enterprise Edition (JavaEE) and Spring. While both have their strengths and weaknesses, this article will focus on Spring and create a simple order management RESTful web application using Spring 4. Although this management system will be simple compared to the large-scale RESTful services found today, it will nonetheless demonstrate the basic thought process, design decisions, and implementation tests required to create a Level 3 (hypermedia-driven) Spring REST web service.

By the end of this article, we will have created a fully functional Spring REST order management system. While the source code illustrated in this article covers the essential aspects of the order management system, there are other components and code (such as test cases) that support the main service that are not shown. All of the source code, including these supporting aspects, can be found in the following GitHub repository:

Categories: Java

Project Comprehension: Understanding Java Projects Efficiently

Javalobby Syndicated Feed - Thu, 21-Sep-17 00:01

Let's start with a bit of theory.

A modern Java application is a complex system that frequently operates as a node in a larger enterprise network. By the time a new developer joins the team, the project will likely have been in development for a couple of years and contain code contributions from dozens of developers, most of whom left the project long ago. Documentation is not always up-to-date and accurate, and only a few team members may have a comprehensive picture of the project (whom you'll have to catch for short Q&As in between meetings, code reviews, and emergency deployments).

Categories: Java

The JVM on Fire – Using Flame Graphs to Analyse Performance

codecentric Blog - Wed, 20-Sep-17 23:00

Currently there are several tools available to analyse your application performance and show the results. Traditionally these results are either shown in some kind of table form, either flat or as a tree view. Flame graphs are relatively new and take a new angle to show the results.
Furthermore, flame graphs can be generated on various levels; tooling hooking into the JVM, but also on (Linux / MacOS) OS level.

In this post I’m hoping to give you some idea about what flame graphs are, how to read them and what tooling is available to create them.

What are Flame Graphs?

Flame graphs were invented by Brendan Gregg as a means to show profiling results. Or, as he puts it:

Flame graphs are a visualization for sampled stack traces, which allows hot code-paths to be identified quickly.

Below you will see an example flame graph from a Spring Boot demo application.

Flame graphs are generally created from the results of sampling profilers. These will create stack samples which can then be transformed / folded to get the right format for generating the flame graph. The graph then is generated by the Flame Graph tool by Brendan Gregg, a simple Perl script that will output an SVG image.
The nice thing about the SVG image is that it can be searched and filtered (unfortunately not possible in this blog post), which makes it really easy to traverse. Also the input for generating the flame graph is a simple text file that can be easily hacked to add / filter information!

A flame graph will give you the following information:

  • Y-axis / Height: presents the stack depth
  • X-axis / Width: presents how much time (number of samples) was spent within a method
  • Color: depending on the configuration will e.g. highlight Java, C++, kernel methods

Important to note is that the X-axis != time passing. The stack frames are sorted alphabetically from left to right. So only look at the width, not where they are on the axis.

Compare that to the JProfiler tree view below, where the overview gets lost much more quickly.

As always when looking at profiling results, though, make sure you know what you are looking at. Certain profilers e.g. suffer from ‘safepoint sampling bias’ (therefore we’ll use the Honest Profiler later on). Similar when using instrumentation, because of additional overhead this might mess up the results and is therefore not recommended.

Needed to get started

The really nice thing about flame graphs is that you can generate them for Java only, but also on OS level (Linux and OS X) to get lower level information in there as well. Previously the system profilers could not fill the entire Java stack because information got lost. Since JDK8 update 60 build 19 (and also JDK9) the frame pointer information is fixed by using the option -XX:+PreserveFramePointer. Later on I’ll show both how to generate JVM only flame graphs as well as OS level flame graphs.

If you only like to generate JVM flame graphs, the following tools are needed:

To generate flame graphs for Linux as I’ll show later on, you’ll also need the following:

Generating Java-only Flame Graphs

For this example we’ll use a really simple application built by colleagues to do some CPU profiling: Profiler Schulung. While this will not generate fancy results in any way, it’s simple to run, runs only for a short time, and makes the differences between results on JVM and OS level profiling very clear. The application can be built using Maven.

To generate the Java flame graphs we’ll use the Honest Profiler. Besides not being troubled by the safepoint bias, the profiler also includes code to transform the stack information ready for the Flame Graph tool to be processed (although this is somewhat hidden).

First step is to include the Honest Profiler agent when executing the application. The full command will look something like this:

java -agentpath:/honest-profiler/liblagent.so=interval=7,logPath=/tmp/log.hpl -cp Cpu-0.0.1-SNAPSHOT.jar de.codecentric.training.javaprofiling.cpu.PrimeFinderRunner 1000000 1 1

The application may be started immediately. When finished, this will output the /tmp/log.hpl file containing the raw stack information.
This needs to be converted to the folded stack data as such:

java -cp /honest-profiler/honest-profiler.jar com.insightfullogic.honest_profiler.ports.console.FlameGraphDumperApplication /tmp/log.hpl /tmp/log.folded

From this folded stack information we can now create the flame graph:

/FlameGraph/flamegraph.pl /tmp/log.folded > /tmp/flamegraph-java.svg

If everything went successfully, this should result in the following graph:

You might get a slightly different result, because small code is being inlined. This can be solved either by using the option -XX:InlineSmallCode=100 to prevent inlining except for really small code blocks. Or using the other (preferred) options: -XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints.

As you see in the graph, also some ‘unknown’ AGCT.Unknown Java samples are visible. These could not be mapped to capture the stack information and tools such as VisualVM will not show them at all. In the next step they will become visible with Linux Perf.

Generating Linux Flame Graphs

Now for the interesting stuff, where we’ll use Linux perf_events to do profiling on OS level. What’s important to note is that the perf command runs separately from the Java process, so we’ll first need to start Java and then start the profiling. Also we need to grab the stack information separately to fill in the blanks. As the JVM does inlining, class loading, garbage collection and other stuff, make sure to profile a JVM that is ‘stable’, otherwise stale data is read and certain stack frames might not be able to get mapped.

To make our lives a bit easier, the perf-map-agent tool includes some scripts for running the perf command together with grabbing the stack mappings. There is even one script to additionally create the flame graph but for clarity we’ll do that step manually.

First start the Java application with the frame pointer information enabled:

java -XX:+PreserveFramePointer -cp Cpu-0.0.1-SNAPSHOT.jar de.codecentric.training.javaprofiling.cpu.PrimeFinderRunner 1000000 1 1

Search for the PID of the running process (ps aux | grep java). Then start the profiling for 30 seconds and afterwards automatically fetch the stack mapping information:

export PERF_RECORD_SECONDS=30
perf-map-agent/bin/perf-java-record-stack 

By default this will create some output files in /tmp. We still need the perf_events information to be extracted though:

sudo perf script -i /tmp/perf-.data > /tmp/out-.stacks

And finally we can fold the stack information and create the flame graph in one go:

/FlameGraph/stackcollapse-perf.pl /tmp/out-.stacks | tee /tmp/out-.collapsed | /FlameGraph/flamegraph.pl --color=java --hash > /tmp/flamegraph.svg

Now you should see the following output:

As you can see in the image created, there’s more information visible besides the single running thread. These are all actions the JVM runs internally such as garbage collection. In the first example from a Spring Boot application much more stacks can be found.

I invite you to install the tooling yourself and give it a go. See what kind of flame graphs are created and how you can navigate them to get all information out. See below for some links to get you started or for more in-depth information.

Cheers!

Interesting Links / Further Information

The post The JVM on Fire – Using Flame Graphs to Analyse Performance appeared first on codecentric AG Blog.

Categories: Agile, Java, TDD & BDD

Reactors.io: Actors Done Right

Javalobby Syndicated Feed - Wed, 20-Sep-17 21:01

In our previous blog, we tried to explore the upcoming features of Java 9. So this time, we will focus on Scala. In this article, we will be looking into a new Reactive programming framework for Scala applications — Reactors.io.

Reactors.io fuses the best parts of functional Reactive programming and the Actor Model.
Reactors allow you to create concurrent and distributed applications more easily by providing correct, robust, and composable programming abstractions. Primarily targeting the JVM, the Reactors framework has bindings for both Scala and Java. 

Categories: Java

Smoothing Out the Rocky Road to Personalization (Part 3)

Javalobby Syndicated Feed - Wed, 20-Sep-17 13:01

dotCMS is an open source, enterprise Java CMS built from the ground up both to use open-source Java standards and to allow you to easily use your own Java code to override or extend dotCMS functionality. Although dotCMS was explicitly designed to make it easy to extend the functionality with your own Java code, dotCMS supports key personalization features natively, which minimizes the work needed to implement personalization on your site so you can focus your own coding efforts on truly sophisticated and custom needs. As we'll discuss shortly, some fairly demanding personalization features are available out-of-the-box, and you can start implementing fairly sophisticated personalization in dotCMS with as little work as changing the name of a single method in your server-side script.

Built-in Personalization Features

dotCMS ships with several very powerful personalization features that address the most common (and most difficult to implement) personalization tasks without having to write your own code:

Categories: Java

This Week in Spring: Microservices, Reactive, and Kotlin

Javalobby Syndicated Feed - Wed, 20-Sep-17 09:01

Hi, Spring fans! Welcome to another installment of This Week in Spring! This week, I've been visiting the Spring and Cloud Foundry teams at Microsoft (this time, in Redmond, WA), and then it's off to San Francisco, CA and San Antonio, TX to visit some customers. So, with that, let's get to it!

Categories: Java

IBM Open Sources WebSphere Liberty Code

Javalobby Syndicated Feed - Wed, 20-Sep-17 05:01

It was great talking to Ian Robinson, IBM Distinguished Engineer and WebSphere Chief Architect, about IBM placing the WebSphere Liberty Code in an open source environment.

The development lifecycle continues to accelerate at an incredible rate. Developers are being asked to turn ideas into production-ready apps more quickly than ever and scale those apps to reach more people.

Categories: Java

Struts Migration Strategies

Javalobby Syndicated Feed - Wed, 20-Sep-17 03:01

This article talks about the strategies for migrating from  Struts 1.1 to Struts 2.0. The Struts framework is one of the most popular web application frameworks in the Java EE world. It has been widely adapted in enterprises and has been a de-facto standard for web applications. Of late, there have been few areas where the Struts community felt the need to improve on some of the architectural areas. Hence, a new version of Struts, Struts 2.x, was released. Therefore, existing applications need to migrate from Struts 1.x to Struts 2.x to leverage the enhanced features of Struts without rewriting the whole application. This document is an effort to allow you to do that.

Table of Contents

  • Introduction

Categories: Java

JWT authentication with Akka HTTP

codecentric Blog - Wed, 20-Sep-17 00:30

The authentication of RESTful APIs is quite an often asked question, so I decided to demonstrate basic authentication via JWT (JSON Web Token) in an example of an API built with Akka HTTP.

JWT working concept

Before we start with the actual coding, we should briefly recap how the mechanism of JWT authentication works. JWT itself is composed of three parts:

  • Header
  • Payload
  • Signature

Header contains a hashing algorithm (RSA, SHA256…) and token type. The payload section is going to be of most interest to you. The payload contains claims. And they usually contain information about the user along with some metadata. Lastly, JWT contains the signature which is used to verify the authenticity of the token sender. The token authentication process and access to secured resources is displayed in the following image.

RESTful APIs are stateless. Upon authentication, there is no a secured session which is generated on server and held in the context of the application followed by the cookie which is being returned and stored on the client side. In case of JWT authentication, we sign in using our credentials, the server generates an access token and we save it on the client side. In order to access secured content on the server, we have to send the access token upon each request (usually as a value of the authorization header). Then the server simply tries to verify the provided access token with a secret key. If the verification is successful, the server provides access to a secured resource. Otherwise, it rejects the request since the user is unauthorized. Our RESTful API remains stateless since the token is not stored anywhere on the server side. Also notice that payload is encoded. Therefore, it’s not smart to put sensitive data into the payload of your JWT! All this sounds great, but what about logging out? The answer is: There is no real logout. Or so to say: There is no immediate invalidation of the access token. And you will probably wonder: “But what if someone steals my access token?”. The best approach is to make your JWT access token expirable. The general rule is to make the access token short-lived and to use a refresh token (“remember me” token) for long lived sessions. Refresh token is stored as a resource (e.g. in database). When the access token expires, a refresh token is sent and checked in order to obtain a new access token. When you delete the refresh token from the data store (upon logout) and when the access token expires, then you will simply have to login again in order to obtain a new refresh and access token. For the sake of simplicity, we will only implement authentication with expirable an access token.

Akka HTTP implementation

In this example, beside the Akka HTTP library, we will use authentikat-jwt which is one of JWT implementations for Scala. Also, we will use circe and akka-http-circe JSON libraries for content unmarshalling. First, let’s create a new Scala class and its companion object – HttpApi. In the companion object, we will create a case class which will represent our login request:

final case class LoginRequest(username: String, password: String)

And we will define few properties for JWT:

private val tokenExpiryPeriodInDays = 1
private val secretKey               = "super_secret_key"
private val header                  = JwtHeader("HS256")

Expiry period will be part of claims. Now let’s add “login” route:

private def login = post {
  entity(as[LoginRequest]) {
    case lr @ LoginRequest("admin", "admin") =>
      val claims = setClaims(lr.username, tokenExpiryPeriodInDays)
      respondWithHeader(RawHeader("Access-Token", JsonWebToken(header, claims, secretKey))) {
        complete(StatusCodes.OK)
      }
    case LoginRequest(_, _) => complete(StatusCodes.Unauthorized)
  }
}

Let’s take a deeper look into this method. We are sending credentials as JSON content. Again, for the sake of simplicity, we will just check whether the username is “admin” and the password is “admin”, too. Regularly, this data should be checked in a separate service. If the credentials are incorrect, we simply return “unauthorized” HTTP status code. If the credentials are correct, we respond with “OK” status code and the JWT (the access token). JWT contains two properties in its claims:

  • user – which is just a username
  • expiredAt – the period after the JWT will not be valid anymore

Where “setClaims” method looks like this:

private def setClaims(username: String, expiryPeriodInDays: Long) = JwtClaimsSet(
  Map("user" -> username,
      "expiredAt" -> (System.currentTimeMillis() + TimeUnit.DAYS
        .toMillis(expiryPeriodInDays)))
)

The login curl command looks like this:

curl -i -X POST localhost:8000 -d '{"username": "admin", "password": "admin"}' -H "Content-Type: application/json"

And response looks something like this:

HTTP/1.1 200 OK
Access-Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4iLCJleHBpcmVkQXQiOjE1MDI0NTkyNzUzMTV9.fgg-H47A3GswZF92Bwtvr0avkezg3TcPhCb_maYSLUY
Server: akka-http/10.0.9
Date: Thu, 10 Aug 2017 13:47:55 GMT
Content-Type: text/plain; charset=UTF-8
Content-Length: 2

OK%

And that’s it when the login mechanism comes in. Pretty simple.

The JWT can be obtained from the “Access-Token” header and saved on client side. Upon each request, we will have to send the JWT as a value of the “authorization” header in order to access secured resources. Now, we are going to make a special directive method “authenticated” which will check JWT validity.

private def authenticated: Directive1[Map[String, Any]] =
  optionalHeaderValueByName("Authorization").flatMap {
    case Some(jwt) if isTokenExpired(jwt) =>
      complete(StatusCodes.Unauthorized -> "Token expired.")

    case Some(jwt) if JsonWebToken.validate(jwt, secretKey) =>
      provide(getClaims(jwt).getOrElse(Map.empty[String, Any]))

    case _ => complete(StatusCodes.Unauthorized)
  }

The method first tries to obtain value from the “authorization” header. If it fails to obtain that value, it will simply respond with the status “unauthorized”. If it obtains the JWT, first it is going to check whether the token expired. If the token has expired, it is going to respond with “unauthorized” status code and the “token expired” message. If the token has not expired, it will check the validity of the token and if it is valid, it will “provide” claims so that we can use them further (e.g. for authorization). In all other cases, the method will return the “unauthorized” status code. This is what the “isTokenExpired” method looks like:

private def isTokenExpired(jwt: String) = getClaims(jwt) match {
  case Some(claims) =>
    claims.get("expiredAt") match {
      case Some(value) => value.toLong < System.currentTimeMillis() 
      case None        => false
    }
  case None => false
}

And this is how “getClaims” method looks like:

private def getClaims(jwt: String) = jwt match {
  case JsonWebToken(_, claims, _) => claims.asSimpleMap.toOption
  case _                          => None
}

Finally, we can apply our “authenticated” directive on some route which will make it secured requiring access token:

private def securedContent = get {
  authenticated { claims =>
    complete(s"User ${claims.getOrElse("user", "")} accessed secured content!")
  }
}

Final route will look like this:

def routes: Route = login ~ securedContent

In order to access resources returned by the “securedContent” route, we will have to provide the JWT we got upon login as a value of “Authorization” header:

curl -i localhost:8000 -H "Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4iLCJleHBpcmVkQXQiOjE1MDI0NTkyNzUzMTV9.fgg-H47A3GswZF92Bwtvr0avkezg3TcPhCb_maYSLUY"

And the response will look like this:

HTTP/1.1 200 OK
Server: akka-http/10.0.9
Date: Thu, 10 Aug 2017 14:08:28 GMT
Content-Type: application/json
Content-Length: 38

"User admin accessed secured content!"%

After we have finished with the building of routes, we are going to finally add the code in the HttpApi class which is going to be an actor used to “spawn” Akka HTTP server:

final class HttpApi(host: String, port: Int) extends Actor with ActorLogging {
  import HttpApi._
  import context.dispatcher

  private implicit val materializer = ActorMaterializer()

  Http(context.system).bindAndHandle(routes, host, port).pipeTo(self)

  override def receive: Receive = {
    case ServerBinding(address) =>
      log.info("Server successfully bound at {}:{}", address.getHostName, address.getPort)
    case Failure(cause) =>
      log.error("Failed to bind server", cause)
      context.system.terminate()
  }
}

A full working example can be found here.

The post JWT authentication with Akka HTTP appeared first on codecentric AG Blog.

Categories: Agile, Java, TDD & BDD

Hamcrest vs. AssertJ

Javalobby Syndicated Feed - Wed, 20-Sep-17 00:01

During RESTful API testing, it’s not uncommon that you would need to call a REST endpoint and validate its response to check its functionality. But how you can validate if something is working correctly or not? The answer is — assertions. Assertions are the cornerstone of the complete testing process, whether RESTful APIs or other components. When we say “testing assertions”, we mean checking that a boolean expression is true, unless there is an issue or bug with the tested use case.

In RESTful API testing, you might deal with API specific assertions like response codes or length validation. In addition, there will always be plenty of situations where you would need to perform general assertions on a daily basis even if you are only working with APIs. These could be variable validation, dates comparison, and so on.

Categories: Java

Domain Specific Languages in Kotlin

Javalobby Syndicated Feed - Tue, 19-Sep-17 21:01

If you’ve been following my recent posts about Kotlin, you’ve probably noticed me mentioning Domain Specific Languages (DSL) already. Kotlin as a programming language provides some powerful features that allow us to create those DSLs. One of these features, which I also already introduced, is called Function Literals with Receiver, and others are the invoke convention or infix notation.

In this post, we’ll have a look at the concept of DSLs and certainly see how we can create one with Kotlin in a relatively simple example.

Categories: Java

Spocklight: Group Assertions With verifyAll

Javalobby Syndicated Feed - Tue, 19-Sep-17 13:01

We all know writing tests or specifications with Spock is fun. We can run our specifications, and when one of our assertions in a feature method is invalid, the feature method is marked as failed. If we have more than one assertion in our feature method, only the first assertion that fails is returned as an error. Any other assertion after a failing assertion is not checked. To let Spock execute all assertions and return all failing assertions at once, we must use the verifyAll method. We pass a closure with all our assertions to the method. All assertions will be checked when using verifyAll, and if one or more of the assertions is invalid, the feature method will fail.

In the following example specification, we have three assertions in the feature method check all properties are valid. We don't use the verifyAll method in our first example.

Categories: Java

JNBridge Introduces Java.VS

Javalobby Syndicated Feed - Tue, 19-Sep-17 09:01

Thanks to Wayne Citrin, CTO at JNBridge for sharing with me the early-access program in Q4 for Java.VS, a first-of-its-kind Java extension for Visual Studio. Designed for professional and enterprise developers and teams, Java.VS provides capabilities for the full editing and development of Java code in Visual Studio, continuing the JNBridge tradition of making the incompatible, compatible.

The latest addition to the JNBridge product portfolio adds Java to the list of languages that can be developed using Visual Studio and makes one of the top IDEs available to Java developers. Java.VS supports all the Visual Studio IDE features that developers expect, including IntelliSense, auto-completion, error detection, debugging, compiling and building. It also supports Visual Studio source code control tools. Java.VS can be used to build solutions for any industry or application. Development teams currently using Visual Studio and all its Professional and Enterprise features can even use Java.VS to develop integrated software.

Categories: Java

Testing HTTPS Web Services With Cucumber

Javalobby Syndicated Feed - Tue, 19-Sep-17 03:01

In this article, I am writing a small example on how to test HTTPS web services using a Java REST client in a Cucumber test.

Any Java developer can have to test web services on DEV, PRE-PRODUCTION, or PRODUCTION, and in order to avoid regression, BDD methodology is appreciated.

Categories: Java

NoSQL Options for Java Developers

Javalobby Syndicated Feed - Tue, 19-Sep-17 00:01

The Java community is one I know and love, so even though a NoSQL database is rarely tied to a language, I’m writing this article for you Java developers around the world. In this article, I’ll show you several options for NoSQL databases. After exploring all the options, I’ll narrow the choices down to the top five based on Indeed Jobs, GitHub stars, and Stack Overflow tags. Then I’ll let you know if they’re supported by Spring Data and Spring Boot.

Why NoSQL?

NoSQL databases have helped many web-scale companies achieve high scalability through eventual consistency: because a NoSQL database is often distributed across several machines, with some latency, it guarantees only that all instances will eventually be consistent. Eventually consistent services are often called BASE (basically available, soft state, eventual consistency) services in contrast to traditional ACID properties.

Categories: Java

Java Modularity: A Personal Journey

Javalobby Syndicated Feed - Mon, 18-Sep-17 21:01

Java 9 was delayed so many times because of Project Jigsaw, and you might have been hearing a lot about modules, modularity, and other stuff, so what it’s all about? What the heck is modularization and what do we mean by a modularized platform? What's the Java Platform Module System (JPMS) all about? Is it going to be a revolution in Java ecosystem?

This post is my exploration of the most important thing that happened to the JDK, the module system. I will explain what modularization is, why you need it, and how you can create your modularized project.

Categories: Java

Java Message System Introduction

Javalobby Syndicated Feed - Mon, 18-Sep-17 13:01

In this article, I will talk about Message Orientated Middleware (MOM) and how it is implemented in Enterprise Java by JMS. Also, I will discuss the typical use cases that suit the use of JMS and different terminology used to talk about messaging solutions such as Publisher/Sender, Destination/Topic/Queue, and Subscriber/Receiver. I will introduce the two types of message topology: point-to-point and publish/subscribe.

Data Access Layer

In the typical architecture of a Java EE application, the data access layer has technologies that communicate with data stores such as Java Persistence API (JPA), Java Connector Architecture (JCA), which connects your application to enterprise information systems (EIS); and Java Message Service (JMS).

Categories: Java

Thread Slivers eBook at Amazon

Syndicate content