Vaadin Framework: Java web apps, GWT clients, and license limits

Where Vaadin Framework 7 and 8 fit

Vaadin Framework targets Java developers who want to create modern web applications without working directly with low-level browser technologies. Its stated development model lets application code remain in Java while the framework handles the browser-facing implementation. That is the central distinction from frameworks centered on hand-written HTML, CSS, and browser JavaScript, although the README does not provide enough implementation detail to compare build output or runtime behavior with a specific alternative.

This repository covers Vaadin 7 and Vaadin 8. Both use GWT as the base of their client-side implementations. Vaadin 8 also contains compatibility classes for Vaadin 7, which is important for applications carrying older application-server or component assumptions forward. The repository directs developers of newer Vaadin versions to `vaadin/platform`, where the web-component-based code is located.

The repository should not be treated as the normal home for new Vaadin Framework development. Its README says that development now happens in a private repository. It also says the repository is used for issue tracking and no longer accepts pull requests. Developers looking for the current web-component-based Vaadin platform are therefore sent to a different repository.

Server, client, shared, and compatibility structure

The repository layout exposes the framework's main code boundaries through separate Maven modules. Directories include `server/`, `client/`, `shared/`, `client-compiler/`, `client-compiled/`, and `compatibility-client/`, with corresponding server, shared, compiled-client, theme, and GAE compatibility areas. This separation is consistent with the README's statement that GWT forms the base of the client-side implementation.

Based on that repository structure, an application depends on server-side and shared Java code while the framework also maintains client-facing modules and compiled client artifacts. Compatibility code has its own top-level directories, reflecting the need to preserve Vaadin 7 behavior in Vaadin 8. Additional modules cover themes, OSGi, Liferay integration, push, a BOM, testing, and the Eclipse environment.

The README does not document the request lifecycle, session model, widget-state serialization, or exact browser protocol. It would therefore be misleading to claim a particular startup sequence or describe how a UI state change reaches the server. The defensible architectural summary is narrower: Java application code is supported by a multi-module framework, GWT implements the client side, and Vaadin 8 carries dedicated compatibility modules.

Licensed release boundaries in the repository

License status changes at specific versions, so selecting a version cannot be treated as a routine Maven coordinate decision. The code represented here reflects Vaadin 8.14.3 and Vaadin 7.7.17, identified by the README as the last releases available under the Apache-2 license. It also states that users may continue using those releases and may fork and maintain the framework themselves.

The boundary is version-specific. Vaadin 8 open source maintenance ended in February 2022. Extended support is stated to remain available until February 2032. Starting with 8.15.0, commercial Vaadin licenses apply, first CVDLv4 and then VCL from 8.19.0 onward. The README names the current license as the Vaadin Commercial License.

Vaadin 7 has a different boundary. Open source maintenance ended in February 2019, and extended support is stated to remain available until February 2029. Commercial licensing begins at 7.7.18 with CVDLv4, while VCL applies from 7.7.37 onward. The README specifically permits use of Vaadin 7 code through 7.7.17. This text is licensing information, not legal advice, and the `LICENSE` file plus the terms linked by the README should be checked for a particular deployment.

Getting started through the documented Vaadin 8 path

The README does not give a self-contained install command, Maven dependency, application class, or runnable hello-world example. It instead directs users to the Vaadin 8 tutorial and the Vaadin 8 documentation. Because no verified dependency coordinates or startup command appear in the README, this review does not invent a code example.

A developer starting an application should open the tutorial linked under “Using Vaadin 8 to develop applications,” then use the Vaadin 8 documentation for the application structure and component guidance applicable to the chosen release. If the application is being prepared for Maven-based assembly, the relevant project-specific detail to verify is whether the desired extended-maintenance Framework source and artifact are available through Maven Central under the commercial release terms that apply.

The repository's development instructions in `README-DEV.md` apply to contributors building the framework itself, not to developers merely creating an application. That file is the documented starting point for a working framework-development environment. The README also warns contributors to pay particular attention to workspace preferences. Since pull requests are no longer accepted, this route is for local development or investigation rather than a proposed contribution to this public codebase.

Why public repository activity does not mean open development

The repository is not marked as archived, and its last push was on 2026-10-14. Recent release entries include Vaadin Framework 8.32.2 on 2026-10-12 and 7.7.55 on 2026-10-14. Those dates show repository and release activity, but they do not establish public source development. The README gives the explicit boundary: no new code is released here from Vaadin 7.7.30 and Vaadin 8.15.0 onward because development occurs in a private repository.

There is also an important source distinction for later releases. The README says that source attached to GitHub releases reflects the state of this repository, not the source of the corresponding Extended Maintenance release. Access to Extended Maintenance source is described as requiring contact with Vaadin sales. Consequently, a GitHub release asset should not be assumed to reproduce the proprietary maintenance code.

This creates an upgrade cost for teams that have historically treated GitHub source availability and artifact availability as equivalent. They may receive a courtesy release notification while needing commercial terms for the artifact and separate access to the maintenance source. The changelog files `CHANGELOG-VAADIN7.md` and `CHANGELOG-VAADIN8.md` cover later version history, but release metadata alone does not provide source access or public fix history.

Vaadin Framework versus the newer Vaadin platform

The real architectural alternative identified by the project is the newer web-component-based Vaadin platform in `vaadin/platform`. It is not simply another version number in this repository. Vaadin Framework 7 and 8 use GWT as the base of their client-side implementations, while the README directs newer web-component-based Vaadin development to a separate repository.

For an existing application, migration is not documented here. Compatibility classes can reduce the risk of small Vaadin 7-to-8 adjustments, but their presence does not prove that every component, integration module, or deployment setup can move unchanged. Teams with Liferay, OSGi, GAE, push, or legacy compatibility dependencies must inspect their specific module usage rather than assuming that compatibility-server directories eliminate migration work.

For a new project, the decision turns on lifecycle and licensing first. This repository explicitly describes its public maintenance boundary and closed-source development model. The Vaadin platform is the documented destination for new web-component-based work. For an existing Vaadin 8 application, staying within that model may avoid a migration, but it requires acceptance of commercial release terms and separation between public repository release assets and Extended Maintenance source.

Editorial conclusion

Teams maintaining an existing Vaadin 7 or 8 application should first verify the exact release, source availability, and applicable license before changing their build. New projects that require an active public development path should prefer the newer web-component-based Vaadin platform because this repository states that Vaadin Framework development has moved to a private repository and pull requests are no longer accepted.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. vaadin/framework on GitHub