The problem may occur when the algorithm is trying to hash the latest stripe. For the latest stripe it can request the bytes from the latest and penultimate chunks. As a solution, it was decided to read the stream until the end if we are at the penultimate block.
GitOrigin-RevId: da68cd5e81f6aa7ed8d51b1bcad1dee983034e8f
JpsModuleReferenceImpl and JpsLibraryReferenceImpl won't resolve if the new implementation is used, so parts of JpsModel which aren't converted to use the workspace model, also need to use *Bridge implementations.
GitOrigin-RevId: 25eb3336d29457ae0c735d74e42960e87cc89b49
JpsModuleExtensionBridge API is introduced which allows converting child entities of ModuleEntity in the workspace model to child elements of JpsModule in the build process.
GitOrigin-RevId: 86277abed01980441b40f7eec3bcd16ca57e040f
Unlike the old implementation, the new one may call JpsComponentLoader.loadComponent multiple times for the same file, so it's better to cache content to speed up loading.
GitOrigin-RevId: 4c3630f24bdcb8740ef5cd3ba6d414febb0f9d77
Data which is present in the workspace model is taken from it, other components are loaded from xml files as before.
GitOrigin-RevId: 368e2b15aa055bc3489fb944c334379f10f2725e
The new implementation based on the workspace model behaves slightly differently for some projects with invalid configurations, tests should tolerate this.
GitOrigin-RevId: fa5a7c888aa60ff27507bff3b9a05fc3d68ececc
Production code sorts modules before saving. Also, this is needed to simplify testing loading in the new implementation of JPS model (IJPL-409).
GitOrigin-RevId: f540342b831bf73cb0e717d51b92da323201edaf
This is needed to test loading external configuration in the new implementation of JPS model (IJPL-409) and to avoid conversions between Path and String.
JpsCompilerConfigurationTest changed to load the project configuration using JpsSerializationManager API and migrated to JUnit5.
GitOrigin-RevId: a9d85b2b8797cdecbc43c07339ad89511823d758
JpsModelFromTestData utility is added which uses JpsSerializationManager instead of creating JpsModel and calling JpsProjectLoader directly. Tests are migrated to use it instead of extending JpsSerializationTestCase. This is needed to use these tests to verify the new implementation of JPS model serialization (IJPL-409). Also, the tests are migrated to JUnit 5.
GitOrigin-RevId: 874f0b01ea6ae5d31666b2dafb843052cc017024
This is needed to refactor simplify JpsProjectLoader to allow reusing its code in the new implementation of the JPS model (IJPL-409).
GitOrigin-RevId: b88fb246454601489e7133df4b078e5e52f6da58
JpsProjectExtensionWithExternalDataSerializer is introduced to support project components which may have data in the external storage. Code related to loading the compiler configuration is moved from JpsProjectLoader to JpsJavaCompilerConfigurationSerializer. This is needed to refactor JpsProjectLoader to allow reusing its code in the new implementation of the JPS model (IJPL-409).
GitOrigin-RevId: c0e64c02c49e4a451da9b9743c240227bd6465a4
This will produce more very short-living garbage which looks harmless. Matcher class has about 20 fields inside. Keep aside that some of them are arrays, Matcher probably occupies 100-150 bytes in the memory. I.e. there will be 150-225MB of garbage for mid-size project like idea ultimate (~1.5M files). Looks acceptable, because preliminary experiments showed that this will decrease 2nd scanning by ~10% (10sec -> 9sec) because of better parallelization when indexing on 19 threads. More parallel environments (like dev pods) should probably show even better parallelization.
GitOrigin-RevId: 450ccf3105d31be2703e4da859a59f1ee6351b8e
Implementations for the following elements are provided for now:
* modules: content, source and excluded roots, custom properties of modules and source roots, dependencies;
* libraries: roots and custom properties;
* SDKs: roots and custom properties;
* java: custom properties of modules and dependencies.
GitOrigin-RevId: 1829d8defa1b36148abfbd063264defdd6c16014
This is needed to reuse it in the new implementation based on the workspace model (IJPL-409).
GitOrigin-RevId: a749b014ea5d28a574c3b1999f23d4376ed27c4c
This is needed to provide a new way to compute Java-specific properties in the new implementation based on the workspace model (IJPL-409).
GitOrigin-RevId: 6c70ab849acee3da22448400a6b6d08662dcab69
This is needed to reuse the common logic in the new implementation based on the workspace model (IJPL-409).
GitOrigin-RevId: 6082830eea7b13a6bae8545ae03286cba6df97c8
Mark as internal members which aren't supposed to be used by plugins. In particular, methods which modify the project model are excluded from API because they are supposed to be called from the implementation code when loading the project configuration from disk. Also, their presense would complicate migration of the JPS model's implementation to the workspace model (IJPL-409).
GitOrigin-RevId: fa717a689aba627a0a4e5bd768413447b8fc574b
Extract CompilerConfiguration.addNewProcessorProfile method to allow plugins adding new profiles without using ProcessorConfigProfileImpl directly. For now, constructors of the latter are not marked as internal, but all other methods are.
GitOrigin-RevId: 7724f865866598daf8ca4b4f6ce48283c203feb1
This is needed to simplify the creation of JPS model's new implementation (IJPL-409). It seems that currently in ultimate monorepo these methods are used in tests only.
GitOrigin-RevId: b4b8f2f13b6e15c26488f2c6060558cfbfbae862
Reduce visibility and mark as internal elements which aren't supposed to be used from plugins. This is also needed to migrate the JPS model to delegate to the workspace model (IJPL-409).
GitOrigin-RevId: 8e2db16140a23f4ba073235f46f48a338a6c2292
