Many users of JavaParser are asking to implement lexical preservation, i.e., the ability of parsing a Java source file, modifying the AST, and get back the modified Java source code, keeping the original layout.
Currently, this is not supported by JavaParser: you can parse all Java 8 code with JavaParser, get an AST, but then the code obtained is pretty-printed, i.e., you lose the original formatting and sometimes comments can be moved around.
Hi, Spring fans! In this tip, we’ll look at the Codecentric Spring Boot Admin and the Ordina JWorks Microservices Dashboard
When I work with Scala collections, I always keep in mind that there are two types of operations that I can perform: transformation operations and actions or aggregation operations. The first type transforms a collection into some another collection. The second one type returns some value.
After this short introduction, I want to focus on particular Scala collection functions, which I count as some of the most useful and amazing parts of my everyday work. Some of these functions are to transform collections, and the rest of them return a particular value after application. And at the end of the article, I want to show you how these functions can be combined in order to solve a concrete problem.
Proper encapsulation leads to a complete absence of "naked data." However, the question remains: How can objects interact if they can't exchange data? Eventually, we have to expose some data in order to let other objects use it, right? Yes, that's true. However, I guess I have a solution that
Say that this is our object:
There are several ways to construct an object instance. The most common way is to use, of course, a ‘new’ keyword. However, as with anything else, both theory and practice have decided to make this more complicated, and invent new fancy terms for it.
The GoF are not authors of the “static factory pattern,” however, it is one of the most famous and simple construction patterns in any object-oriented programming language, and it is used in PHP.
While working on one my projects, which uses Akka HTTP, for routing, I came across a situation where we had to use a custom rejection handler. It was a worthy thing to be shared with all and, hence, this article was born.
Rejections are used by Akka HTTP to help us handle error scenarios more aptly. When the filter directives do not let a request pass through their internal body because the filtering conditions are not met, a rejection occurs. This rejection flows through the chain of the routes to see if any route can handle it. If there is a route in the routing structure that can take it, it's good to go. Otherwise, it generates a rejection.
In this talk, we’ll cover the host of new features that have been added to Spring Boot 1.4 to help with testing. We’ll discuss how to unit test your code, how (and when) to involve Spring in your tests, and talk about the various tools and libraries that you should be using. Taking a simple application, we’re going to add:
Unit tests for basic components.
Thank you all for following this year's Java Calendar. Here is the complete list with all the articles:
I want to share with you a small piece of my project. It’s about Scala. To be more precise, it’s about the simplest way of learning Scala. Why did I say the simplest? Well, because I have a solid knowledge of mainstream problems that occur during Scala studying.
After three years of Scala usage, I can confidently say that it’s an awesome programming language. Looking back to the days when I started learning Scala, I feel stupid because I didn’t follow going about it in an optimal way. My attempts to understand Scala concepts were unsuccessful. It was only through persistence that I first achieved some results.
Today, we are going to do some nonsense calculations. Is there a Santa, and if yes, how many Santas can we expect to find in the world?
Let us start with some assumptions. When this article was written, there was an estimate of 7,472,085,518 humans on Earth. Let us disregard the guys who live on the International Space Station, because presumably, Santa's reindeer cannot operate in near-Earth orbit. Luckily for those guys, Elon Musk can deliver their presents via Space X's delivery rocket instead.
Equals and hash code are fundamental elements of every Java object. Their correctness and performance are crucial for your applications. However often we see how even experienced programmers are ignoring this part of class development. In this post, I will go through some common mistakes and issues related to those two very basic methods.
What is crucial about mentioned methods is something called "contract." There are three rules about hashCode and five about equals (you can find them in the Java doc for Object class), but we'll talk about three essential. Let's start from hashCode():
Spring Boot has simplified the deployment of Java-based web/API applications drastically. It has eliminated the process of deploying a WAR file into the web container provided by Tomcat or any other application servers. It has brought in a new paradigm shift where the container libraries (like Tomcat/Ubuntu/Jetty) are themselves embedded along with application classes/JAR within the fat Spring Boot JAR — thus making it a truly standalone application and a candidate for microservice development.
But, there are few minor challenges, which a spring boot developer would face, when deploying the Spring boot application.
Today's tip is about mappable types. Traditionally, we Java developers have relied on inheritance and types with a number of methods to support the convenient use of our classes. A traditional Point class would contain x and y coordinates and perhaps also a number of functions that allows us to easily work with our Point.
Imagine now that we add new shapes like Circle, and that Circle inherits from Point and adds a radius. Further imagine that there are a bunch of other geometric shapes like Line, Square, and the likes that also appear in the code. After a while, all our classes become entangled in each other and we end up in a messy hairball.
Some weeks ago, I read a tweet that contained this picture, and someone said, "That's why Value Types are helpful!" After that, I remembered a few situations that happened a few years ago, and I decided to write about it.
I've seen a lot of validation code that was quite crazy. Most of the time, there were methods with parameters like Doubles, BigDecimals, or Strings followed by lots of business validations at the beginning of each method. These business validations were scattered around the whole codebase, and most of the time, it was copy-pasted. These contain technical bits like null checks and business validations. Situations like these are really suboptimal for several reasons.
Spring Boot, the new convention-over-configuration centric framework from the Spring team at Pivotal, marries Spring’s flexibility with conventional, common sense defaults to make application development move swiftly and enjoyable. It’s ideally suited for building microservices and distributed systems and makes streamlining DevOps practices simple. Join Spring Boot contributor Eddú Meléndez Gonzales for a look at what Spring Boot is, why it’s turning heads, why you should consider it for your next application (REST, web, batch, big data, integration, whatever!) and how to get started.
Recorded at SpringOne Platform 2016.
Speaker: Eddú Meléndez Gonzales
The Java log levels showdown: SEVERE FATAL ERROR OMG PANIC
After this past weekend, there was a comment that totally threw me off guard, which is why, today, I want to cover some of the most popular languages out there.
A month ago, I was asked if I wanted to be a mentor for the HackOHI/O 2016 Hackathon competition Since I was in a competition earlier in my career, I absolutely said yes. The Hackathon was late last month, and I went with a fellow colleague. It was amazing to see the innovation and immense amount of work going into these projects.
Today's tip is about using Enums as parameters to indicate method behavior. Let us here the fairy tail of Prince Sort and it will be more apparent why this can be a good thing.
Once upon a time there was a Prince with a sort method like this:
StackWalker gives the snapshot of the stack trace of the current thread at any given point of time and has methods to walk over it. Benefits of using StackWalker over Thread::getStackTrace() (prior to JDK9), which are missing in prior releases, are:
Part 1: Installation
Part 2: Keywords
Part 3: Implementing Keywords in Java
Part 4: Selenium2Library as a drop-in replacement for SeleniumLibrary
Part 5: Integration with TeamCity CI-Server
Part 6: Integration with Jenkins
Part 7: File Processing
Part 8: Working with Collections
Part 9: Wrap-Up and Conclusion
The year 2016 is coming to an end and as this is the “Robot Framework Tutorial 2016” it is kind of the last chance to add the final chapter for this tutorial. Everything started in January this year with the first blog post on how to install the Robot Framework. But it is not the idea of this post to simply list again all the previous ones. They are anyway listed at the top of this page. But there is one – for me a bit exceptional – blog post I would like to mention though. That is the one about keywords. Not only are keywords the central concept of the Robot Framework, but I also started a small example project on GitHub for it. This was extended in the course of the tutorial when new concepts have been shown which I personally like a lot, having one central place for all these examples.
But now to something completely different :-). I like the tool for reasons not all being totally objective. But of course there are quite some really strong pros for the tool as there are cons as well (very diplomatic of me, right?). I would really like to avoid getting into bullet point lists of pros and cons here, but instead let’s talk about the people I believe the Robot Framework is a good choice for. Those are definitely “testers” or “QA-people” and yes, there are projects out there that have these roles still explicitly. Typically testers do not have a strong programming background, but are for sure totally capable of writing tests and own keywords using the Robot Framework. And let’s face it: They are much more dedicated to the testing subject than developers taking over that role (temporarily).
On the contrary we are having those projects that do not have an explicit testing role. Still there is a need to write automated tests and developers like to stay inside their IDEs. Therefore tools like JBehave or Cucumber are typically first choice in those cases.
Then we can have a mixed approach of course where developers are implementing the testing functionality. This can be done basically using any of the before mentioned frameworks. Then the testers are building their tests on top of this. This can really work well, but I also think it limits the creativity of the testing to some extend. Whenever there is something where no testing functionality is available yet the tester needs to request that one from a developer and then wait for it while doing something else. This could be ok, but it is something really worth thinking about and discussing in the team before choosing a testing framework and thus also a testing approach.
What about letting the users of the application write some tests, assuming this is possible and wanted from an organisational point of view. I have simply never seen that this worked out. And even if it might look as if it works in the beginning – while a lot of effort is put into this from the development team – it dies in the long run. There are simply too many technical hurdles that might seem small to us, but they are not. It starts with simple syntactical problems and cryptic error messages. Now the Robot Framework brings its own IDE, which has really made huge progress since that blog post has been written. But still I doubt that it really works out for non-technical users. Another problem is that tests must be put under version control. If users should write tests they must use the version control system as well. Not good! Let alone the problem of defining testdata that allows tests to be executed repeatedly.
There might be very specific circumstances where this is working, but most of the time I think it simply doesn’t.
Consider what you want to achieve and your team structure before choosing a testing framework. On the positive side the Robot Framework has really lots of ready-made testing functionality, aka keywords and a very active forum. Those could be assets in the project one should not easily dismiss. Then on the other hand implementing all testing functionality in Java can be very appealing, especially for more developer-centered teams. This might also allow for tests on a bit “lower level” easily without the need to test everything using the GUI. So what can be said: It depends :-).
Just choose wisely and have a really good Christmas time :-).
The post Robot Framework Tutorial 2016 – Wrap-Up and Conclusion appeared first on codecentric AG Blog.