Does size matter? That’s a question that’s been around for a while, and the answer is up for debate. But this is JavaFX, and the answer is a resounding, "Yes, size does matter." I’m not saying that user interfaces need to bigger to be better, I’m talking about controlling the size. If you don’t control it properly, you will end up having undesirable results. What if the user makes the window so small that part of the display gets cut out never to be seen again — unless the window is made larger again of course. Maybe it's resized so large that there is loads of empty space around the edge of the interface. So you're going to need to keep the size under control. And you're in luck, as in this article, I'll cover some ways to do that.
I am going to be reusing some of the code that I wrote in previous posts, so have a look at Getting Started with JavaFX and JavaFX Charts look pretty good! for explanations of some of the code that will be used here.
After we’ve made our first big steps into functional programming in the last post, we will talk about Optionals in today’s part.
At first glance, a lambda looks like a shorthand version of an anonymous inner class. But they are not. Today, we'll cover the differences between lambdas and AICs
The key to lambda implementation is the InvokeDynamic instruction, introduced in Java 7. This allows dynamic languages to bind to symbols at runtime.
In Java 8, one of the best features is lambda expressions. The entire idea is passing a behavior to a method. Inspired by functional programming, we can pass methods as arguments of other methods. Methods taking other methods as arguments are called higher order functions.
The benefit of this type of design is you can pass behavior and values together so that a single method can perform all types of actions on those values.
The RebelLabs Developer Productivity survey is one of the most important ones in the Java ecosystem. It is widely circulated and generally tends to have the most data points. The survey has always asked about Java EE as well as Java SE adoption. The results of the 2016 survey look encouraging for Java EE generally and Java EE 7 specifically, particularly given the seemingly perpetual nay-saying around Java and Java EE in predictable corners of our ever "colorful" industry.
The RebelLabs survey is a bit different from the similar DZone survey in that it asks participants to make mutually exclusive adoption choices. You can either be a Java EE user or a Java SE user. You are only allowed to choose one specific version of Java EE. While this may not be entirely reflective of more complex scenarios in real life, it does make the results a bit more interesting from an analytical perspective. The 2016 results for Java EE adoption are shown in the graphic below. A clear majority of developers — 58% — identified themselves as Java EE users. This is truly remarkable for a mature open standard like Java EE with a number of non-standard product vendors aggressively positioning themselves as competitors to Java EE for many years now. Even more encouragingly developers seem to be solidly behind Java EE 7 — far more so than previous versions including Java EE 6. It is especially good to see the number of J2EE users at a low percentage.
Once you get started down the road of applying functional principles to your programming, eventually you will stumble across some academic white beard mumbling something about total functions, or your local FP evangelist bemoaning that the third of the deadly coding sins (after mutation and side-effects of course) is the rampant blasphemy of programmers either knowingly or unknowingly writing partial functions.
So you may be wondering now what exactly total and partial function are. I mean, most people don't write half a method, right? So how can any function not be total as long as it compiles? And what's so bad about partially applied functions? Isn't that supposed to be a functional programming thing? (Hint: That's not the same as a partial function).
One obvious fact about tests that is often overlooked is: Tests are code. This implies that the tests, as any kind of code, have to be read, understood, and maintained. We’re smart, educated people, familiar with all the craftsmanship practices of Clean Code, so we keep our tests clean. And yet, if you’re like me, you might be dissatisfied with the way some of your tests look. Not so long ago, I found my way to resolve this problem – the Spock framework.
Spock tests are written in Groovy – a concise JVM language with a lot of syntactic sugar. Groovy has quite a few features that make it a perfect fit for testing:
I held back writing this post because I felt the last thing the Java world needs is another Lambda post, but the main reason I blog is to improve my ability to explain technologies, so I decided to do it anyway.
The syntax of a lambda is simple:
Today I finished my migration of a (small) demo app to the new Vaadin 8 API.
First of all: Vaadin 8 has a compatibility layer. Everything you may have used with Vaadin 7 will still work with Vaadin 8, you just have to change some package names in your import statements. (for example, UI gets ui.v7) and everything will work out of the box with Vaadin 8.
Apache Maven is a build or a total project management tool that scores over its predecessors such as ANT for Java builds with the following advantages:
I have created an alumni project that is a dynamic web archive with a Servlet that says “Hello, Alumni”.
2016 — what a year it was for Java EE! As most of you probably remember, around spring time, some worrying rumors started spreading in the Java community about Oracle abandoning Java EE. To make things worse, crucial members of the Oracle Java EE team were leaving, including Cameron Purdy, Reza Rahman, Mark Heckler, and John Clingan.
On top of that, various discussions on the Java EE spec mailing list seemed to suggest that the priorities had shifted and the Oracle team was not focusing as much on Java EE development as was expected from the community. All this was happening with no further explanation from the Oracle team.
In my post Dipping into Java 8 Streams, a comment was added that I should explain what the Common Fork Join Pool is and how it is linked to parallel streams. Honestly, I had never heard of it, so I set out on my quest to find the answer somewhere on the Internet and make this post to attempt to follow up on the posted comment. Unfortunately, I wasn’t able to reach the understanding about this subject that I hoped I would, so I am going to write what I found out from doing some research and from debugging some code myself. If you think anything is missing, then leave a comment. This is, after all, a place to learn!
So let's start with something I am pretty sure about. When you use a parallel stream, it will run its process in multiple threads when appropriate. Now that’s what you would expect, as it has the word parallel in its name. But what it doesn’t say is that all the parallel streams that you create will share their threads from one Common Fork Join Pool. This shouldn’t be a problem if you're just using a single parallel stream every now and then, but if you're running a few of them concurrently, it might run slower than expected, as the threads they use are being shared between them. Another piece of information to note is that although it is called a parallel stream, it does not run concurrently by default. The Collection that is being processed is done multi-threaded but the main thread will still wait for the overall process to finish.
Need a little spring in your step? Tired of all those heavy web servers and deploying WAR files? Well, you’re in luck. Spring Boot takes an opinionated view of building production-ready Spring applications. Spring Boot favors convention over configuration and is designed to get you up and running as quickly as possible.
In this blog, I will walk you through the step-by-step process for getting Spring Boot going on your machine.
With Eureka, Zookeeper, Consul, and others, service discovery is an integral part of almost all of the new elastically scaling software systems. Instances or nodes of the application space can come, go or get restarted at any time and the system has to automatically adopt and discover new members.
Service discovery often works in two or three easy steps. Either the runtime environment (e.g. Microsoft Azure, Amazon EC2, or Google Compute Engine) automatically register the new virtual machine (VM) instance at startup time and push metadata or the application registers itself while starting up. While the application is running, it might push a keep-alive notification to the service discovery system from time to time and when being shut down it’ll remove itself. The keep-alive is used to remove an instance for any kind of failure that prevents the application from gracefully removing itself.
Most likely, your job is heavily focused on helping your organization modernize for the digital era. As the days of purely Object-Oriented Programming and related frameworks come to a close, enterprises migrating to distributed, cloud infrastructures are embracing a different approach: the Actor Model.
When it comes to distributed computing, the Actor Model is the great-grandparent of it all. Created by Carl Hewitt in 1973, Forrester Research notes, “the Actor Model is seeing renewed interest as cloud concurrency challenges grow.”
Hi, Spring fans! In this tip, we’ll look at the Spring Data Couchbase support in Spring Boot 1.4. We'll see how you can incorporate a Couchbase database (in this case, their movie demo database) into a Spring Boot app.
Earlier versions of Mockito had the limitations of not being able to mock final classes or static and final methods, etc. However, with Mockito2, the team has introduced an incubating, opt-in feature to take mocking a level ahead. We can now mock final classes using this incubating feature.
I have prepared a HelloWorld example to give a simple demo on how to use this opt-in feature.
Caching is becoming an integral part of most of the web and mobile applications to enhance the speed of providing data. It helps reduce roundtrip calls to the datastore (Database, REST service, file, etc.). Spring provides cache abstraction, which enables integrating caching providers (EhCache, Hazelcast, Infinispan, Couchbase, Redis, etc.) with the existing Spring application.
In a scenario where the application is up but the cache you are connected to fails, how do you continue to function without an outage? And how do you continue to use the cache once it is brought up without any interruptions? There are multiple solutions for this problem, but we will go through how to short circuit the cache in the Spring environment.
As some of you are aware, the Java EE Guardians and DZone jointly conducted a community survey to help determine Java EE 8 features prior to JavaOne 2016. You may also be aware that we shared the results of that survey with Oracle before the details of the renewed Java EE 8 scope was announced. Now is a great time to start analyzing those results a bit more. I've already done a high-level summary of the results. In this entry, I'll dig specifically into the responses for HTTP/2 and Servlet 4 support in Java EE 8.
Here is how the survey phrased the question:
A unit of work transaction either succeeds or fails and rolls back. So suppose we are dealing with transferring money from one account to another. Now, say money from one account is already debited but when it gets credited to another account, there was an exception. Obviously, the ideal scenario would be for the debited action to roll back. Otherwise, we're dealing with an inconsistent state (and some very angry account owners).
So if we use transactions in our business logic, we can ensure the logic under the transaction works as a unit and that it will roll back if anything is found to be wrong.