Tests failing while running master branch on Java 8

[Aryan Patil (AryanP45)]

• Running gradlew test on main branch of jpf-core .Using Java8 [openjdk version "1.8.0_362-362" ]

Still 5 tests are failing .

• Running gradlew test on java-10-gradle of jpf-core .Using Java8 [openjdk version "1.8.0_362-362" ]

Default configuration of build.gradle

sourceCompatibility = 11

targetCompatibility = 11

Changing compatibility  versions doesn't seem to do anything.

• Running  gradlew test on java-10-gradle  branch of jpf-core .Using Java11 [openjdk version "1.8.0_362-362" ]

can anyone suggest me what i might be doing wrong ?

[Cyrille Artho]

Hi,

Are you sure you have updated your files correctly?

On branch `master`, the sourceCompatibility and targetCompatibility settings are 1.8.

With these settings, JPF should build and test without errors for recent versions of the JDK.

[Aryan Patil (AryanP45)]

Hey cyrill, thanks for replying 

but these tests 

• ClassLoaderTest. testGetResourceAsStream
• ClassLoaderTest. testGetSystemResourceAsStream
• URLClassLoaderTest. testFindResource
• URLClassLoaderTest. testFindResources
• SAXParserTest. testSimpleParse

are failing again after i checked 

[Cyrille Artho]

I am using the same Java version, and all tests pass (on Mac OS). I think the CI environment uses Linux, and all tests pass there, too.

Is there perhaps an issue with your base system? The first couple of tests failing suggest a file system incompatibility (perhaps the tests are not as portable as they should be).

[Aryan Patil (AryanP45)]

yeah it seems that the failing tests are not compatible my OS ( Windows 11) , I tried testing it on Ubuntu OS now all cases passing successfully.

[Cyrille Artho]

OK, this is still not ideal. If you are good at Docker and can create an image that runs the regression test under Windows, then we will be happy to add that to our CI setup.

[Aryan Patil (AryanP45)]

sure , I'll try

[Aryan Patil (AryanP45)]

As an applicant for the JPF support project in GSOC this year, I would like to mention that I can undertake the Docker integration task alongside the project if given the opportunity.

[Cyrille Artho]

Thank you, that would be a useful contribution as JPF still depends on Java 8. (Maybe we will support Java 11 well enough to migrate after this summer.)

(This is also for others who are reading this message this week:) Please be aware that the GSoC timeline shows that we (and any other organization) had to state our preferences (in terms of proposal ranking) a couple of days ago. Therefore, a contribution now may positively impact an application next year, but the decisions for this year (from our side) have already been made.

The process continues as follows: Google will decide soon how many slots it will give us. The final results are going to be announced by Google, and no organization is allowed to share their intermediate results (such as rankings) with students.

[Aryan Patil (AryanP45)]

I want to express my appreciation for the opportunity you have given to be a part of your organization. Although I did not get accepted into GSOC this year, I am still very interested in contributing to your organization in any way possible.
I am interested in the topic of docker integration and I would love to start a discussion about it in this group. I believe that this "containerizing" helps to reduce the time and effort required to set up and configure the testing environment on multiple machines or platforms, making it easier to test the software across different operating systems and configurations.  I am eager to learn more about how it can be integrated into your organization's workflows.

Thank you for your consideration, and I look forward to working with you in the future.

[Cyrille Artho]

There are two things that could be containerized:

1. The automated regression tests (the 900+ unit tests that are run every time as part of continuous integration/CI). A docker image makes the test setup independent of platform-specific configurations and allow us to run them on different computers easily. Right now, the CI setup is based on github actions and cannot be executed in other ways.

2. The JPF application itself. I am not sure how this would be done in the best way, though. It would be easy to create a docker image that can run the built-in examples, but in order to be useful, the image would have to support users in running their own examples. It would therefore need an entire development environment so users cannot just copy examples to the docker image, but actually work with them (and fix small mistakes before running JPF again).

Providing "vim" would work as a relatively stable image that can be used in the long term, but more complex environments like "VS Code" change weekly, so they would not be suitable for this kind of image, unless there is a way to automatically update them.

Option (1) is smaller in scope and easier to achieve, so I suggest that. Option (2) would need more discussion.