Repository navigation
Conversation
Script changes preparatory to introducing modules (in the layout we found to work in VSJ4).
This allows us to test creation of the several kinds of Javadoc publication.
We approximate the package structure we need for safe type system construction and control of visibility developed in the VSJ prototype. We reduce the breakage this causes by temporarily making some things public (opposite to the goal).
|
The modularisation that seemed initially a structural question, led to functional improvements and new thoughts: you just can't control visibility as desired and bring the type system into existence in the old way. So the change developed in the prototype repo is extensive. I'm going to merge a lot of it to this branch. Unfortunately, this will look like a big change all at once. It is really the product of a lot of false starts and re-work, that I'm sparing future readers. Objects like |
This is a batch of changed and new files supporting the re-worked type system. It is not a consistent state, so don't test it.
The core types have evolved with the type system. These changed and new files relate to that. It is not a consistent state, so don't test it.
Exceptions have changed to be more like their implementation in CPython. They cannot all be distinct Java types because of the need for class-assignment, but some can.
We add/update descriptors and exposure mechanisms that have not already slipped through, and a two actual modules. Many classes lack their full set of features. This is not yet a coherent state we can test.
We commit support for 3.11 byte code. Developing support for JVM byte code leads to some refactoring of these classes. This is the last of the core runtime code, so we include some updated tests. The test suite as a whole should not be expected to pass on this commit.
We update the existing tests to match changes in the core. We have some tests still to add. The test suite as a whole (as currently committed) ought to pass.
The type system springs into existence when needed. We have a battery of tests to check that it does so in full working order, irrespective of the trigger (even concurrent and re-entrant triggers).
Type attribute access is not correctly synchronised yet, so it's a mystery that this test doesn't fail.
|
I added my changes in batches that do not correspond to the order of development but have something to do with each other. However, it is not possible to run (or even compile, I expect) until where I take off the "skip ci" marker. After that, code is all additional and (as you can see) the unit tests run. The last set contains one test. It is interesting because, to my mind, the feature tested is incorrectly synchronised. It should fail, but doesn't on platforms I have tried (x86). |
As well the files git merge cannot merge, some classes have moved and other features (exceptions for example) have changed. We address those changes during the merge.
This PR, when it has all its change sets, will restructure the Jython 3 code into a Java module
core. The objective is to control visibility of objects that will become API, while allowing us to use package structure internally to the project. (Without Java modularity, everything we make public for re-use between packages internally, becomes public externally.)It is intended that there be more than one module eventually, but always a small number.
We are applying some off-repo learning (in VSJ4). The first step (adding module definitions) does not achieve the objective: public classes must be allocated to packages that are either exported or not, and in some cases a class must be divided between them. The off-repo work also advanced the functional state of the implementation so we shall bring that in too.
This gets quite difficult so the PR will be draft for a while.