In the previous part of this blog, I talked about the most important steps to get your project to compile with the latest Framework version.
The migration has been done through the first three steps mentioned here, and in this post, I will go over the least complicated steps of migration. Steps 4 and 5 cover the modernization of your project with the latest Framework 8 features. If you are in a hurry, you can do this later on as well, and use the new APIs only for new Vaadin code.
- Upgrade dependencies in the POM file
- Run Maven goal vaadin:upgrade8
- Upgrade Add-ons
- Upgrade non-data components
- Upgrade data components
- Back to the future
Continue reading “Upgrading to Vaadin Framework 8 (Part 2 of 2)”
With a major release, you would usually expect major modifications in the core of the framework. But this time, the migration is not too complicated. Not only because of the migration tool provided to make a smooth transition from Framework 7 to Framework 8, but also because of the similarity in many of the components’ APIs.
Continue reading “Upgrading to Vaadin Framework 8 (Part 1 of 2)”
C/C++ libraries expect to be able to change the internal implementation details of opaque data types from release to release since such a change has no external ABI consequences. If an opaque data type is placed in process-shared memory (when allowed by the standard) and shared with multiple processes, each process must ensure they are using exactly the same version of the library or they could fail in unexpected ways during library upgrades. The placement of opaque data types in process-shared memory is never allowed unless otherwise stated by the library documentation. For the GNU C Library (glibc) you may place pthread_mutex_t, pthread_cond_t, and sem_t in process-shared memory as allowed by POSIX. Failures using these types occur because a process started more recently may have a newer version of the library for the type and that version may have a different understanding of the internal details of the type. The problem has always been one for the developer to solve, but without help, this problem is so intractable as to make it difficult to robustly use opaque data types in process shared memory.
We will cover opaque data types, what they are, why you would use them, and how library upgrades play into the problem, and what might be done by the application developer.
Continue reading “C/C++ library upgrades and opaque data types in process shared memory”