No.

When migrating from Vaadin 8 to Vaadin 14, there is a good basic Vaadin Documentation on Upgrading from Vaadin 8. The documentation also lists replacement components to use in Vaadin 14, but the page doesn’t mention replacement APIs to use. So, here we go.

Awesome blogpost by Chris Kiehl: Software development topics I’ve changed my mind on after 6 years in the industry. Excellent thoughts, and I agree with almost everything. A couple of thoughts from me below.

A quote from Steve Jobs first.

A bit of a clickbait title there; sure, there has been countless articles in this regard (die/won’t die/blah). I’m not interested in when or how; here I’ll talk about the why. In my Java Is Not Dead, Java Is Obsolete article I touched the subject from an evolutionary point of view (think of Java as a meme - it is alive only when there are Java practitioners around. Since the stream of new practitioners shrinks every year because there are more lively memes, the “Java” meme will shrink and die as the pool of its hosts will shrink). Here, I’ll touch other topics.

Building on How to Enable HTTP and HTTPS in Spring Boot which is a bit outdated nowadays.

Vaadin 8 used to have the ComboBox.setNullSelectionAllowed(true) function which enabled the user to select an empty item in the ComboBox. Vaadin 14 does not seem to have the same function, so what to do next?

Covering large area with a reliable WiFi signal may be tricky. The idea is to simply add more access points to different parts of your house, essentially creating a network which together covers the entire house. All of the APs (acronym for Access Point) share the same SSID; the client (your laptop or mobile phone) then knows that it can connect to any of those APs to obtain the access to the internet. As you move the device within your house, the device will eventually lose connection to the original AP and needs to reconnect to a different AP. The promise here is that the device is free to reconnect (this is called “Roaming”) to any other AP without having to obtain a new IP or reconfigure its networking much - this way the device can keep the TCP/IP connections open and continue communication. In order to keep this promise, all APs must be connected to the same LAN network, sharing the same netmask and gateway.

Simply create the following Servlet Filter which will start the transaction and will commit/rollback after the request has been handled:

Grid is the most complex component in Vaadin, and it’s not easy to figure out what to do when it starts behaving slow. However, here are couple of tips to try. Try these tips out regardless of whether you’re using Vaadin 8 or Vaadin 14.

microk8s is an excellent way to have a Kubernetes server up-and-running in no time on your Ubuntu machine. In this article we’re going to have the vaadin-kotlin-pwa app running in Kubernetes with a PostgreSQL database. That will require the following steps:

A quick tip on how to add a (Vaadin) session init listener: first, create a VaadinServiceInitListener as documented at VaadinServiceInitListener tutorial.

There are two main entrypoints of error handling in Vaadin:

Vaadin 14 kinda supports IE11, but there are limitations. The performance hit is substantial, for example vaadin-grid may perform 5x-10x slower in IE11 than in Chrome or Firefox, on the same machine. This performance hit will not be fixed (it can not be fixed) - if you need a performant site for IE11 then Vaadin 8 is the best choice.

In today’s highly unscientific test, I’m going to compare two projects:

After months of development and testing, the Vaadin Gradle Plugin is now official, hooray! :-D

If you need to preserve the state of certain route during the duration of user’s session (e.g. to preserve a half-filled form so that the user can return to the form and fill it afterwards, or to create a multi-route wizard with a back+forward navigation), you may use the following code to cache the route components in your session.

After Linux is installed on your SSD, don’t forget to enable the Discard operation, to let your SSD know which blocks are free to be reclaimed.

So apparently the tablet needs to support something called Widevine in order to play Netflix/Amazon Prime Video in Full HD. At first I thought it’s not such a big issue to watch movies in 720p, but there’s a big but:

According to Bintray blogpost, Bintray and JCenter are dead effective May 2021. That’s too bad - I’ve been using Bintray to avoid Maven Central ridiculously complex deployment process. Looks like that can not be avoided anymore.

Having e.g. Alt+Z bound to certain functionality in your webapp helps users to control the app quickly. However, certain browsers may reserve certain key combinations (e.g. Ctrl+W to close a tab) and will not pass those combinations to your app.

In short, Vaadin 14 does NOT support session replication and must be run with Sticky Sessions. I’ll let Leif summarize the situation:

TCP/IP was established as a means to have a bi-directional pipe where random packet reordering can not happen and where the information is reliably delivered to the other party. It succeeded with the “reordering” part, and failed miserably with the “reliably” part. Read on.

In the past I have written an article regarding Launching your Vaadin apps in Docker and Running WAR apps in Docker with Jib. However, what if you don’t have Java installed at all on the machine (e.g. it’s a CI server) and therefore can’t run Gradle build? Or what if you don’t want to have an unfamiliar Gradle script running on your machine (e.g. could be a virus)? The solution is to perform the build itself in Docker as well, by using Docker multi-stage builds.

Long time ago (in 2012) the browsers deprecated Synchronous XMLHttpRequest (XHR) support: Getting rid of Synchronous XHR. Most recently, Chrome 80 dropped Synchronous XHR in Page Dismissal handler altogether. Do/did these changes affect Vaadin?

In case the push is not used, the XhrConnection class is used to send requests. It doesn’t matter whether it’s a Poll request or a “regular” request stemming from e.g. pushing a button - in this case they are equal. The code at XhrConnection:193 suggests there is really no timeout set, and so Vaadin client will happily sit there for 10 hours, awaiting a response to the message it had sent:

Vaadin Push is a tricky complicated beast, based on a complicated push stack. A lot of things can go wrong, causing the Vaadin client to freeze endlessly. Let’s discuss how exactly push works, and what can be done to prevent the freeze.

Vaadin’s synchronization protocol is based on UIDL (UI Diffing Language?). Basically it’s a JSON file, listing what have been changed since the last UIDL update. For example, if you set a new caption to a TextField with connector ID 42, you will be able to observe this information in the UIDL sent from the server to the client.

Say you have a script such as

I’ve read an amazing article Who Needs Lombok Anyhow, which discusses Lombok and its quirks. I personally feel no need for Lombok since Kotlin contains all the features offered by Lombok, but there was something else that caught my eye.

You need to be careful when picking an USB enclosure for your SATA SSD drive: the problem is that not every USB enclosure supports the SATA TRIM / USB UNMAP command, which is a must for keeping your SSD healthy.

Sometimes Vaadin 14 fails mysteriously, which is very unfortunate: it now uses LOTS of JavaScript code, frameworks and tools. Those things are unfamiliar to server-side guys, and it’s really hard to tell what to do, should one of JavaScript toolchain fail.

Sometimes Vaadin 14 fails mysteriously, which is very unfortunate: it now uses LOTS of JavaScript code, frameworks and tools. Those things are unfamiliar to server-side guys, and it’s really hard to tell what to do, should one of JavaScript toolchain fail.

Neither the Vaadin Gradle Plugin nor the Vaadin Maven Plugin really document what they’re doing under the hood. When something goes wrong, it’s very hard for a server-side guy like myself to know what’s going on, especially since the entire JavaScript client-side landscape is pretty much a mystery to a Java guy. Hence this blog post.

The Vaadin documentation is a good source of initial info for Vaadin, but unfortunately in certain cases it simply doesn’t go deep enough. This is especially true with respect of the toolchain Vaadin uses, and the files it relies on. Therefore, this blog post.

This post is not about how Spring/Dependency Injection hurts ability to navigate and code readability nor it’s about There’s no place for Spring in post-annotation world. This post is a rant.

A summary of reasons why I tend to avoid MySQL (or MariaDB for that matter) and use PostgreSQL instead:

In this setup we’ll have a Kubernetes Cluster with a Load-balancer, running your app from a docker image, connected to a Google Cloud SQL running MySQL.

Imagine typing something into your application’s TextField, and suddenly bam: the TextField loses the focus or something else gets focused instead, for no apparent reason. This article will summarize a list of items to review, to find out which pesky component or code steals your focus.

When trying to fix some browser-side issue in your GWT components, it is often useful to modify those component sources while your app is running, then refresh your browser with F5 and immediately see the changes done in Vaadin Button. This blogpost describes how to configure Intellij to do just that.

If you ever tried to parse XML on Android the encouraged way, trying to parse a simple XML <foo>Hello World!</foo> will yield the following shitty code:

The absence of any sane way to parse XML in Android (the official Google-endorsed way of parsing XMLs is ridiculous, low-level, hard to use and error-prone, as are all other aspects of programming with Android) pushed me to write yet-another-XML-parsing-library called konsume-xml, and that made me realize just how horrible and evil annotations are.

In the past I have written an article regarding Launching your Vaadin apps in Docker. That required you to write the Dockerfile. However there is even simpler way: Jib.

The problem with this machine is that it only outputs 1920p to a 4K monitor with Ubuntu, which is pretty annoying. According to the Dell Inspiron 13-5379 spec the connector is HDMI 1.4a, which should support 4K. However, only HDMI 2.0 supports 4K with 60FPS, HDMI 1.4a only supports 4K with 25 or 30 FPS. My Inspiron employs Intel i7-8550U which should support 4K at 60FPS.

Previous article mentioned four of the most important yet most basic resources to monitor for the health of your JVM, but also of your system:

If your server-side JVM app chokes up when serving 20 concurrent users, then there is something very wrong. Luckily, it’s usually very easy to find out the initial hint as to where the problem may lie.

When you need to use Push with your Vaadin app, you generally have two choices: Long Polling and Web Sockets. Which one to use?

This happens to me every now and then. I’m developing a Vaadin app, then I switch to another one and suddenly the Vaadin session expires immediately, or Vaadin complains that the cookies are disabled. What does this bug mean and how can we work around that?

Karaf is an OSGi container rather than a WAR container. Hence it is not as easy to deploy your WAR into Karaf as opposed to, say, Tomcat. You basically have three options:

• Split your WAR into separate jars, add OSGi descriptors to all of those so that Karaf recognizes them as OSGi bundles, then plug your servlets into Karaf’s pax-web something. That’s a lot of work.
• Repackage your WAR as JAR with JARs, add OSGi descriptor so that Karaf recognizes that as a big bundle, then plug your servlets into Karaf’s Pax-Web. That’s still a lot of work.
• Use WAR Deployer and just copy your WAR to the deploy/ folder. Ta-daa! This is the easiest way of deploying WAR to Karaf, the one that doesn’t require you to add OSGi manifests to your WAR and/or tackle the XML bundle configurations. Let’s go.

The Vaadin-on-Kotlin framework contained the support for feeding the outcome of a SQL query to the Vaadin Grid for the long time. However, since VoK is based on Kotlin, Java developers probably avoided this solution and looked for a Java-based example. Well, here it is:

While I don’t recommend using Spring because of simplicity reasons, there are valid reasons to have Spring support. For example when building UI for an already existing Spring-based backend, or when gradually converting a legacy application to VoK.

I’d like to write something positive, but I can’t - my experiences with CouchBase had been highly negative. I’d even dare to say it’s an unfinished piece of junk; if you need to setup a syncing platform from your Android app, avoid CouchBase like a plague.

Creating Vaadin UIs from Java code has the following disadvantages:

Proper building construction is to have a proper design which includes all latest state-of-the-art components and follow all safety precautions. The building won’t collapse and it will be great. If you however use this approach with software, you will fail.

The client-side in Vaadin 10 is completely different than the one in Vaadin 8 and the layouting manager from Vaadin 8 is completely gone. Vaadin 10 layouting is therefore something completely different to Vaadin 8 layouting. Naturally, it is something completely different to Android layouting. Here we will focus on layouting completely configured from server-side, and not from a CSS file.

There are lots of Android SDK sucks and android development is a pain rants indicating that development on Android is a horrible experience. Instead of repeating the same thing over and over again, I’ll try to sum up why I will definitely prefer Vaadin-based PWA for my next project over Android SDK:

In the previous blog post we’ve used self-signed certificate with Docker Tomcat. However, in order to have a properly protected web site, we need to use a proper set of certificates. We’ll use the Let’s Encrypt authority to obtain the keys at no cost.

It is possible to use pem-style certificates with Tomcat Docker image, without any need to store them first into the Java keystore. This is excellent since not only it is easier to generate self-signed certificate with the openssl command, this can also be used with certificates produced by Let’s Encrypt.

I have to admit upfront that my brain is somehow incompatible with JPA. Every time I try to use JPA, I will somehow wind up fighting weird issues, be it LazyInitializationException with Hibernate, or weird sequence generator preallocation issues with EclipseLink. I don’t know what to use merge() for; I lack the mean to reattach a bean and overwrite its values from the database. I don’t want to bore you to death with all of the nitty-gritty details; all the reasons are summed in Issue #3 Remove JPA. I think that the number 1 reason of why JPA is incompatible with me is that

I’m sure that Thomas Kriebernegg, the CEO of App Radar will be happy to persuade you that you can make a living by selling Android Apps. He needs to - his way of making a living is to sell services to Android devs so he better make sure there are lots of Android devs; discouraging devs from becoming Android devs would be a financial suicide. But why not trying out your luck? After all, Flappy Birds was making $50,000 a day in ads; Clash of Clans makes millions of dollars. Let me tell you a fucking secret: you are not going to be the author of Flappy Birds and Clash of Clans, and let me tell you why.

Teamcity is quite a nice continuous integration server from Jetbrains. The set up is not that easy though since you typically need to install the TeamCity server itself, and at least one agent which will perform the building itself.

When Kotlin 1.1 brought in Coroutines, at first I wasn’t impressed. I thought coroutines to be just a bit more lightweight threads: a lighter version of the OS threads we already have, perhaps easier on memory and a bit lighter on the CPU. Of course, this alone can actually make a ground-breaking difference: for example, Docker is just a light version of a VM, but it’s quite a difference. It’s just that I failed to see the consequences of this ground-breaking difference; also, performance-wise in Vaadin apps, it seems that there is little need to switch away from threads (read Are Threads Obsolete With Vaadin Apps? for more info).

Let me start by saying that threading model (or, rather, single thread model) provides the most simplistic programming paradigm - the imperative synchronous sequential programming. It is easy to see what the code is doing, it is easy to debug, and it is easy to reason about (unless you throw in dynamic proxies, injected interfaces with runtime implementation lookup strategy and other “goodies” of the DI) - that’s why having such paradigm is generally desirable. Of course that holds only when you have one thread. Adding threads with no defined communication restrictions overthrows this simplicity and creates the most complex programming paradigm.

Nicolas Frankel put some of my feelings into an excellent article Is Object-Oriented Programming compatible with an enteprise context?. During the development of Aedict Online (still as a Java-based JavaEE/JPA app back then, now it’s Vaadin-on-Kotlin-based), when trying to find rows from JPA+DB I often tried to find the necessary functionality on the JPA entity itself. Wouldn’t it be great if, upon user’s log in, we could find the user and verify his password using the following code?

It is indeed possible to write Vaadin 10 Flow apps in Kotlin. Here are a couple of resources to get you started:

Traditionally, the testing of a web portal is done from the browser, by a tool which typically using Selenium under the hood. This type of testing is closest to the user experience - it tests the web page itself. Unfortunately, it has several major drawbacks:

In his blog about comparing Kotlin and Java features, Simon was IMHO too kind. Creating a prototype of some app in Kotlin, then converting the code painfully to Java (simply because Java is company’s lingua franca) and watching it inflate and obfuscate itself is quite an eye-opening experience.

So you have built your first awesome VoK app - congratulations! You will probably want to launch it outside of your IDE, or even deploy it somewhere on the interwebz. Just pick up any virtual server provider with your favourite Linux distribution.

Obsolete as in Cobol - used widely, but on a descendant trajectory. Let’s ask a very simple question:

Or what-if-a-fucking-meteor-falls-down-and-swaps-1s-and-0s

Once a project leaves the rapid development phase and enters the calm waters of maintanenance mode, the programming paradigm changes. Fancy hyped frameworks favored by project creators no longer play important role. What matters most now is the code readability and understandability. The code is already written - now it is going to be read, understood and fixed. After all, that’s usually what happens to the code - it is written once but read by many. This is true both for open-source, but also for closed-source: people in the team come and go, and new team members need to read the code, to familiarize themselves with it.

You have your superdevmode development environment up and running. All is peachy and world is unicorns until you figure out that some pesky bug is only reproducible on a cell phone. Bam. What now?

When trying to fix some browser-side issue in Vaadin built-in components, it is often useful to modify those component sources while your app is running. This way, you can modify e.g. VButton.java, refresh your browser with F5 and immediately see the changes done in Vaadin Button. This blogpost describes how to configure Intellij to do just that.

When doing mobile development with Vaadin, you often develop the app on your dev machine and view the page on a tablet or a phone. Yet, entering your dev machine IP into the phone browser may be tedious and error-prone. There is a way though, to enter an URL to your phone. Via a camera, as a QR Code.

Let’s discuss the most useful cases for the extension methods. First use-case: extension methods allow to apply themselves only selectively. For example, the following method only applies to a list of Person:

Now if there was some way to get rid of that pesky em -> which needs to be written every time one calls the db {} function. If only there was a way we could tell a block to “know” some variables implicitly… Maybe we could throw those “variables” into a class and tell the block to run as some kind of an extension method in that class? That could work - extension methods have direct access to the receiver object methods and variables. Remember our findAll() method?

I’ll get to the forms right away. But first, I want to talk extension methods. They are immensely helpful in adding functionality to objects. Note that Kotlin is not a dynamic language - the methods will not really be added to target classes, it is just a syntactic sugar. Quite delicious, though. So, EntityManager misses the findAll method - let’s fix that. Open the DB.kt file and add this to the end:

Let’s add some database to our hello-world. I’ll use the pure-Java embedded database called H2 which will run as a part of our application, so there is no need for you to install any database engine. Open the pom.xml file and add the following lines at the end of the dependencies element:

Kotlin provides some very interesting language features which are immensely helpful when writing Vaadin apps. Let us start from scratch, building necessary functionality as we progress. The result of this exercise will be a Kotlin-based simple web app, built with Gradle, using Hibernate+JPA o store entities into the database. I will not use Spring nor JavaEE here - the whole thing will run in a pure Servlet environment like Tomcat or Jetty. The complete exercise may take some 60 minutes. I will be using Intellij IDEA Community which you can download for free here: Download IDEA. When installing, just press the “Skip remaining” button to install Intellij with the default settings.

When one tries to migrate her project to a newer version of a framework, it usually helps if the transition is smooth and the original code works without any modifications. This way, you can convert the code to the new API gradually, and never encounter this OMG-shit-doesn’t-compile-everybody-blocked period for a long time.

If you ever used Selenium (or TestBench, which is based on Selenium), you know the pain of configuring the testing browser driver: