vaadin/flow 25.3.0-alpha3

Vaadin Flow 25.3.0-alpha3

on GitHub

Changes since 25.3.0-alpha2

All changes

New features

• Reuse shared metadata cache when scanning
  Commit · Pull request · Issue

  Class and annotation scanning at startup runs many passes (routes, error handlers, web components, lookup, ...), each building a new ClassPathScanner. Because CustomResourceLoader does not extend DefaultResourceLoader, Spring's CachingMetadataReaderFactory falls back to a per-scan cache bounded to 256 entries instead of the application context's shared, unbounded resource cache. Parsed class metadata is therefore discarded and re-computed on every pass, slowing down startup on large classpaths. Keep the filtering CustomResourceLoader as the scanner's pattern resolver so package and JAR filtering is preserved, and override the scanner's MetadataReaderFactory with a single shared CachingMetadataReaderFactory backed by the application context. As the context is a DefaultResourceLoader, the factory now stores metadata in the context's shared cache and reuses it across all scan passes.

Fixes

• Support gradle 9 in plugin
  Commit · Pull request · Issue

  Bump kotlin and dokka versions. Add tests for 9.0.0 and 9.5.0

• Make URL_SAFE_SCHEMES init parameter name consistent
  Commit · Pull request

  InitParameters.URL_SAFE_SCHEMES used the value com.vaadin.safeUrlSchemes, which is inconsistent with every other parameter in the class — none of them carry a com.vaadin. prefix. Since the parameter already shipped in 25.2.1, the old name must keep working to avoid breaking existing configurations. Change the canonical value to safeUrlSchemes and add a deprecated URL_SAFE_SCHEMES_LEGACY constant holding the previous value. AbstractDeploymentConfiguration#getUrlSafeSchemes now reads the new name first and falls back to the legacy name, with the new name taking precedence when both are present.

• Prevent refreshViewport from reloading data from data provider
  Commit · Pull request

  DataCommunicator#refreshViewport used to set the same flag as reset(), which made the flush re-query the item count and re-fetch the viewport range from the data provider. Now it only regenerates and resends data for the items that are already active, matching the behavior of HierarchicalDataCommunicator#refreshViewport. Changes: - The former resendEntireRange flag is renamed to reloadViewportRange (it reloads the viewport range from the data provider and resends it). - A new resendViewportRange flag drives the resend-only path used by refreshViewport: the active range is regenerated through the data generators and resent via update.set without any data provider queries, using the same wire format as before. - If the viewport range changes in the same roundtrip, newly visible items are still fetched from the data provider as they were never loaded.

• Clean up countInstances
  Commit · Pull request · Issue

  Make count instances more effective by not using split that compiles a pattern and generates an array for each invocation.