The Anypoint platform provides various components and built-in functions for integration purposes. Most of our needs in a project can be fulfilled easily, especially when we use the Enterprise Edition. Not only does this include the availability of ready-to-use connectors, but also a quick response from MuleSoft support.
Let's say we have to develop integration project using Community Edition. Obviously, with limited support from them. Although we can rely on the community forum with tons of ideas and discussions, sometimes we face a common impediment from our internal developers. In particular, they resist adopting the Anypoint platform and still engage with their preferred programming language. For example, they do not want to use MEL or expression component, but prefer to write a Java class.
Java has long had a relationship with Builder, usually calling it by the more degenerative term “Factory” or “Factory pattern.” (Technically, what Java calls a “Factory pattern” is typically one of Builder, Factory Method, or Abstract Factory, depending on what precisely looks to be varied and/or encapsulated.)
We start with the target Product:
Thread dumps are vital artifacts to diagnose CPU spikes, deadlocks, memory problems, unresponsive applications, poor response times, and other system problems. There are great online thread dump analysis tools such as http://fastthread.io/ that can analyze and spot problems. But to those tools you need provide proper thread dumps as input. Thus in this article, I have documented 7 different options to capture thread dumps.1. jstack
‘jstack’ is an effective command line tool to capture thread dumps. The jstack tool is shipped in JDK_HOME\bin folder. Here is the command that you need to issue to capture thread dump:
For anyone who pays close attention to Java EE, it has become clear in the past six months that there has been a decline of activity...especially in those JSRs for which Oracle maintains the lead. What's the deal? There has been a lot of conversation in the Java EE community in this regard lately, and I think it is important that the developer community be given a fair timeline of what we can expect for the future of Java EE. The uncertainty is becoming long in the tooth, and the community is becoming more concerned with the future of Java SE and Java EE as time goes on.
Let me give you a bit of background. I'm an expert group member on a couple of JSRs targeted for Java EE 8, those being JSR 372 (JavaServer Faces 2.3), and JSR 378 (Portlet 3.0 Bridge for JavaServer Faces 2.2). At the beginning of 2016, I had noticed that since October 2015 the number of emails on the Expert Group list for JSR 372 had really slowed down. In fact, in the final quarter of 2015, the activity on JSR 372 had slowed down to a near halt, whereas it should be picking up momentum as time moves forward closer to the eventual final release. In late January, I was contacted by a couple of members of the Java EE community, indicating that they also had seen a slowdown of activity and were very concerned. I was then asked to join a community of concerned Java EE advocates on a Slack community...and when I joined and read the backlog of messages I could clearly see that it looked as though Oracle had stopped activity in just about every area of Java EE, specifically work on all of the JSRs that were Oracle-led.
The verdict is in once again on the Oracle vs Google lawsuit regarding Google's use of Java in Android, and no sooner was Google declared the winner than Oracle announced their intent to appeal (at least) once more. The reaction to the verdict has been widespread in technology circles as one would expect, although the reaction is fairly one-sided (see thread examples here and here).
In reading some of the reaction on a range of site, I'm not seeing much (any?) sympathy for Oracle's loss, which might seem odd in a case like this. If you think about high-profile copyright/patent cases or questions of ownership in other industries, the public sympathy tends to be with the owner/creator. Remember Ice Ice Baby? (I'm trying to forget). The public was happy to see Vanilla Ice paying Queen royalties for using their song. Human nature in these types of cases would make one inclined to be behind Oracle, but this is a different case.
This is the first in the data structure reviews and likely the simplest: the humble array. The first issue is the term Array; its term differs depending on who uses it but we will get to that a bit later.
Generally, I think of an array like this:
In the last post, Code Smells - Part I, I talked about the bloaters: they are code smells that can be identified as Long Methods, Large Classes, Primitive Obsessions, Long Parameter List and Data Clumps. In this one, I would like to dig into the Object-Orientation Abusers and the Change Preventers.Object-Orientation Abusers
This type of code smell usually happens when object-oriented principles are incomplete or incorrectly applied.
In the Java EE umbrella every piece of technology is standardized under a JSR (Java Specification Request). The Expert Groups of the JSRs have to deliver the specification, a Reference Implementation, and a TCK (Technology Compatibility Kit). For most of the JSRs, the TCK is licensed as closed-source software and is not available for the public.
That has the implication that any vendor who wants to implement a specific technology has to explicitly apply/ask for/buy the TCK in order to test their implementation and get officially certified. The problem with this situation is clearly that it raises the barrier for potential vendors. Or, in other words, it would be a benefit for vendors to more easily join in the game. Having that said it would then also be more favorable for users of Java EE to have more competition among implementations.
Eclipse-based IDE’s have a powerful feature to make ‘variants’ of the same projects: Build Configurations. Build configurations are a powerful thing in Eclipse: they allow me to make ‘variants’ of a project. The project will share the common things, and I can simply tweak things one way or the other for example to produce a ‘release’ or a ‘debug’ binary of my application without duplicate the project.
Build configurations are managed through either the context menu on the project or with the top menu:
@Cacheable: this annotation is used to declaratively configure L2 (shared) caching for a JPA entityCache Modes
Specified in persistence.xml or during Entity Manager Factory creation (programmatic)
The new Brave web browser is trying to do something radically different with your boring old browser. Brave burst onto the scene at the start of 2016, positioning itself as the latest battleground in the war between ad producers and ad blockers. Brave is built on the promise of faster load times and better privacy protection by blocking web trackers and targeted ads. If Brave users agree to replace those ads with anonymous ads from the Brave network, the user will be paid in bitcoin. Being paid to surf has been the dream of many web aficionados and Brave promises to make it real.The Philosophy Behind Brave
In the first part of notes on Akka FSM, we saw the basics of Akka FSM and the outline of the Coffee vending machine that we planned to build - the structure of the Actor and a list of messages we pass to the Actor. In this second and final part, we will go ahead and implement each of these States.Recap
As a quick recap, let's look at the structure of the FSM and the messages that can be sent to it.
Every so often I’ll crawl out of my Java cave and run into a seasoned dev who has embraced Scala. And I have noticed that not one of them seems to want to go back to Java programming.
Having moved to Java 8 and embraced Optional and streams, I can see the appeal of thinking functionally. Whenever I see a nested for loop iterating over a collection or a bunch of null checks on a class hierarchy, I shudder little. Not only because the code is so ugly, but because for the longest time I didn’t know any better myself.