The functions were in `IjentWslNioFsToggler` and they were non-static. It led to problems:
* Checking VM options required to initialize the service `IjentWslNioFsToggler` which initializes the filesystem, causing race conditions in enabling/disabling code in the benchmark test.
* If something has "vmoptions" in the name, it should be in "vmoptions" class, especially when such a class exists.
GitOrigin-RevId: dc228c196799300461b1b287bc5a1428bb0b91f4
It was enabled first in f6d18f61549ec24a2bc7d307743106d9ae0ce2b0 and 4418f0d2049439b2aea050affc0a9d7d8180cc3f, and it was almost immediately disabled in d676fa4790978878885f039805b00b69624d0975 and 217de367786a4191c04679e501ce5a4340398107 due to found issues.
GitOrigin-RevId: 0ccf3e031ba29dab079e1befa61eb77a1aabae47
It was enabled first in 933cc96dbd1899c1e414b23c4819784a2ee1f9a9 and almost immediately disabled in e0dbcd659af1fd5babd844d9f40a9a5f64d9bc23 due to found issues.
GitOrigin-RevId: e0e6d076a7af10b9c17bf0aa97ffd3db3bf50aab
To enable the new filesystem, some tricky VM options must be specified. Just changing the default value of the registry key is not enough.
The new code brings tooling and constants to ease enabling the IJent WSL filesystem in specific products.
`IjentWslNioFsToggler` stops specifying `-Didea.io.use.nio2` because `com.intellij.openapi.util.io.FileSystemUtil.computeMediator` is already aware of the IJent WSL filesystem and starts to use java.nio without the explicit system property.
`IjentWslNioFsToggler` keeps reacting to the registry key changes, but forces its value into the VM options, literally ignoring the state of the registry. It was done on purpose to make the VM options file the only source of truth and to not deal with registry-vmoptions synchronization issues.
GitOrigin-RevId: 6a3c333f841f87cece56ddc26bcbc284cf1a1ecf
Bugs that are mentioned above are caused by a prompt set after the console was converted. This commit adds an ability to add a listener that is called on a prompt update, so our converter can keep it up to date.
GitOrigin-RevId: f9d5b0b6006c3fe95f87bfb65fec3e34b7dedd95
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
The workspace model uses configurationStore API to load data, and there attributes of the root tag are represented as options in an artificial DeprecatedModuleOptionManager component.
GitOrigin-RevId: 2a0a197e8f41c491d5b9ffd9f707a9e2315f1301
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: 9ebf7519a32dfea2d048181ae5f6db323622d55f
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
And fix cases where null was actually passed. Before, it was easy to forget to check it for null in the implementations.
GitOrigin-RevId: 72b7bf041e873f40ef95db97e897e628a714f756
Modules are sorted in the modules.xml file, but entities may be added in arbitrary order due to concurrent loading. So they should be sorted during conversion to JPS model for consistency with the old implementation and have stable behavior in the build process.
GitOrigin-RevId: 1e12f2930f702b80b089985d8e91cee03da10292
