Move subset of TCK tests that test jakarta.activation library code into this project

[rmcdouga]

I am new to TCKs but it seems like the current TCK code tests two things:

1. Code that is part of the jakarta.activation library
2. Code provided by a library implementing the SPI interfaces

Would it make sense to move the tests that test the code in jakarta.activation into this project and convert them to JUnit5?

It seems to me that this would have several benefits:

1. They would be closer to the code that they test.
2. Running them would become part of the API library build process.
3. They would be easier to run and maintain (given that JUnit5 is a more common skillset than com.sun.javatest).
4. The TCK would run faster with just the implementing SPI tests.

[rmcdouga]

I'm willing to submit a PR if this seems like a worthwhile task.

[lukasj]

I agree there would be benefits, yet this separation is there for a reason - the TCK has different release cycle from the API (ie bug in the test should not require a release of an API), an API to be tested can be implemented by someone else and what we want that library to is to pass exactly same set of tests to name a few.

I also agree that the move to JUnit (or basically to some common unit test library) makes tests easier to run and maintain - there exists a PR for that already

[rmcdouga]

Sorry - I didn't see the existing PR. Thanks for the pointer.

w.r.t. the separation - what you say makes sense in theory but in practice are there any implementations which replace the implementation of FileDataSource provided in the API? What about MimeTypesFileTypeMap? Does releasing a bug fix in the tests for these classes make any difference outside of a new API release?

Perhaps I am misunderstanding the purpose of the concrete classes in the API and in the api .jar. I am thinking that the concrete classes in the api .jar can't be replaced by a implementation provider and so therefore it doesn't really make sense to include them in the TCK.

Just to be clear, I'm only talking about moving the tests that are testing actual code in the api .jar into the api project. TCK tests that run against implementation provided code would remain in the TCK, but does it really make sense for every implementation to test code that is provided as part of the api .jar if they are providing that .jar unaltered?

[lukasj]

Perhaps I am misunderstanding the purpose of the concrete classes in the API and in the api .jar. I am thinking that the concrete classes in the api .jar can't be replaced by a implementation provider and so therefore it doesn't really make sense to include them in the TCK.

Not by an implementation provider but by the provider of an API - anyone can decide to re-implement the API itself. Or even consider simpler use-case - an implementation provider decides to produce a binary which contains both - an API as well as "default" implementation. One cannot say if the concrete API class comes from already tested code and is unmodified or is rewritten without carefully inspecting the code itself in this case.

note that - AFAICT - it is also forbidden to put non-API code, such as tests, into jakarta package namespace

[rmcdouga]

OK, I think I understand. So you want to allow someone to be able to ignore the code in jaf-api, re-implement everything in that project and then be able validate that re-implementation with the TCK.

How likely is that now that the jaf-api code is open source? I can see that happening when JEE was closed source, but it seems less likely to me under the current circumstances. Are there any existing re-implementations?

Sorry to keep at this. I appreciate you taking the time to have the conversation with me...

[lukasj]

How likely is that now that the jaf-api code is open source?

it has been open-source for really long time - since Schwartz open-sourced Java itself during Sun days around 2006. But back to the point - I'm aware of at least two different providers of the API jar itself - Geronimo and ServiceMix - both run at Apache, yet the latter may no longer be valid. As for why they are doing it, I can only guess - it can be different license, improved support for specific environment (OSGi?) or sth else

[rmcdouga]

Fair enough. Thanks for explaining it.