(De)Serialize ApplicationModel (from) to JSON instead of Java Object Serialization

[aloubyansky]

This PR is meant to supersede #50602

It includes the following changes:

• Introduces quarkus-bootstrap-json module that includes a slightly enhanced version of io.quarkus.builder JSON API from quarkus-builder and makes previous users of the quarkus-builder API use the new API.
  • The original API has package io.quarkus.builder[.json], the new API is in package io.quarkus.bootstrap.json, since it's in the bootstrap project.
  • Enhancements include JsonObjectBuilder implementing Map and JsonArrayBuilder implementing Collection and unescaping characters when deserializing (it looks like it was overlooked in the original impl).
• Deprecates io.quarkus.builder JSON API (should it be simply removed?).
• Introduces io.quarkus.bootstrap.model.Mappable interface, that basically defines a method Map<String, Object> asMap(), that allows to represent an application model as a Map.
  • Mappable interface also allows to pass MappableCollectionFactory to asMap() to create instances of custom implementations of Map and Collection.
• Introduces ApplicationModelSerializer utility class to serialize and deserialize ApplicationModel with simple methods.
  • JSON is made the default format.
  • JOS (the legacy format) can be enabled with a system property quarkus.bootstrap.application-model.serialization.format=jos.
• LazySourceDir (used in the Gradle integration) replaced DefaultSourceDir (it's easier to deal with it when serializing and deserializing).

This serialization approach is apparently significantly more efficient compared to Java Serialization - ~2-5 times faster depending on the application model size.

The file a model is serialized to still has .dat extension. It should probably change to .json if the JSON format is used.

[gsmet]

Did you measure the deserialization speed? Because it might also be useful for the SerializedApplication if actually faster.

[aloubyansky]

Did you measure the deserialization speed? Because it might also be useful for the SerializedApplication if actually faster.

Yes, both are significantly faster.

[aloubyansky]

Looking at the native tests failure, it looks like i need to make sure I properly deserialize the config. The original implementation did escape character during serialization but didn't unescape them during deserialization.

[gsmet]

Should we add some tests for the JSON layer? I'm pretty sure that's something Claude could do for us.

[aloubyansky]

We must add tests. I was a bit surprised there weren't any.

[gsmet]

I'll try to see tomorrow if Claude can generate a reasonable set of tests.

[gsmet]

@aloubyansky I pushed a fix and some tests contributed by Claude: they seem to make sense and be good base for the future. Let me know what you think, we can adjust or even drop the commit if you're not convinced.

[aloubyansky]

Great! Thanks!

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 08a5b26.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.