Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] What are the requirements for TCK Signature testing in the future?
  • From: Mark Thomas <markt@xxxxxxxxxx>
  • Date: Wed, 27 Jan 2021 15:20:42 +0000
  • Autocrypt: addr=markt@xxxxxxxxxx; prefer-encrypt=mutual; keydata= mQINBEq0DukBEAD4jovHOPJDxoD+JnO1Go2kiwpgRULasGlrVKuSUdP6wzcaqWmXpqtOJKKw W2MQFQLmg7nQ9RjJwy3QCbKNDJQA/bwbQT1F7WzTCz2S6vxC4zxKck4t6RZBq2dJsYKF0CEh 6ZfY4dmKvhq+3istSoFRdHYoOPGWZpuRDqfZPdGm/m335/6KGH59oysn1NE7a2a+kZzjBSEg v23+l4Z1Rg7+fpz1JcdHSdC2Z+ZRxML25eVatRVz4yvDOZItqDURP24zWOodxgboldV6Y88C 3v/7KRR+1vklzkuA2FqF8Q4r/2f0su7MUVviQcy29y/RlLSDTTYoVlCZ1ni14qFU7Hpw43KJ tgXmcUwq31T1+SlXdYjNJ1aFkUi8BjCHDcSgE/IReKUanjHzm4XSymKDTeqqzidi4k6PDD4j yHb8k8vxi6qT6Udnlcfo5NBkkUT1TauhEy8ktHhbl9k60BvvMBP9l6cURiJg1WS77egI4P/8 2oPbzzFiGFqXyJKULVgxtdQ3JikCpodp3f1fh6PlYZwkW4xCJLJucJ5MiQp07HAkMVW5w+k8 Xvuk4i5quh3N+2kzKHOOiQCDmN0sz0XjOE+7XBvM1lvz3+UarLfgSVmW8aheLd7eaIl5ItBk 8844ZJ60LrQ+JiIqvqJemxyIM6epoZvY5a3ZshZpcLilC5hW8QARAQABtCJNYXJrIEUgRCBU aG9tYXMgPG1hcmt0QGFwYWNoZS5vcmc+iQI3BBMBCgAhBQJKtA7pAhsDBQsJCAcDBRUKCQgL BRYCAwEAAh4BAheAAAoJEBDAHFovYFnn2YgQAKN6FLG/I1Ij3PUlC/XNlhasQxPeE3w2Ovtt weOQPYkblJ9nHtGH5pNqG2/qoGShlpI04jJy9GxWKOo7NV4v7M0mbVlCXVgjdlvMFWdL7lno cggwJAFejQcYlVtxyhu4m50LBvBunEhxCbQcKnnWmkB7Ocm0Ictaqjc9rCc1F/aNhVMUpJ0z G1kyTp9hxvN6TbCQlacMx5ocTWzL0zn6QZhbUfrYwfxYJmSnkVYZOYzXIXIsLN5sJ9Q4P8tj Y4qWgd+bQvOqPWrkzL9LVRnGOrSYIsoM5zWdoj1g1glMzK/ZqJdRqqqBhe6FYTbXipz8oX8i mCebcaxZnfLhGiqqX+yDa3YUwDiqom+sZOc0iXGvKkqltPLpNeF0MVT7aZjalsQ/v2Ysb24R Ql9FfjfWmvT8ZPWz8Kore1AI4UcIIgFVtM+zuLlL9CIsGjg+gHDE2dhZDY0qfizlHL9CoAWU DM3pIfxM2V4BRn1xO+j/mModhjmYLZvnFVz4KGkNO7wRkofAANIWYo3WI5x83BGDH371t3NR rrpSSFP0XpQX6/Leaj2j6U6puABL2qBxhscsO6chc3u4/+019ff+peZVsc9ttcTQXsKIujmM b8p2sk5usmv6PKVX3oW/RAxpbVHU5kZ5px1Hq7mMQdZfLs5ff4YymXBH02z4/RmSzPam0Xb5 uQINBEq0DukBEADCNEkws5YroBmbu8789Xf006gTl5LzD/Hdt3sAp9iCfPgucO+l7U+xbo1X HTMJQwEVfS+Rx3RbaLYRG+hU7FuJLQB/5NaCDNRuqw5KHyQtJUH+zo84IqqfMzG8aOSdHg1y r2xKH4QTmgQONBu/W0xEZmZro6TjYNwkk2pwXK2yuImZPUOy+mK1qF8Wm3hTtkPE+FFSNFIa eHDoTGmx/0Riu/K7dNJTrC0TlRpn2K6d60zB53YYTc+0DYSDyB0FupXiAx/+XEGn3Q7eNi2B V6w50v5r51QP8zptiFflMfFKNAfV8xS5MteQd98YS5qqd/LPo3gS5HFPQaSL0k3RTClv7fQN HcZFqmv0OWpix6zm2npYxhqsTDGeSa52/uXehVXF5JubYFifMSLpbGVZqdrmG5hr2cycxsjF iY0zJOaRitmN/JWbOGLiwrcN4ukKNyFntFG5jPaFnJdx9rHfyJNeF9cgv9JlZeFxJ6WqIAhl KOuH3K8/py0SPE6ZOFfRo0YUxvh25K/siOcPLm613aOxyY7YfQ8ME2vgn7I0mAtg9am+YFDa bGqj839odwZdzZv2T2mUHnybFTJFBuMWGWKYstYDS6eZEmhupbPvUKkDug/mO+gdo+pSKF9Y S6DM5RtCdTNJq4NZY50ypBb5RSj+INHPocIp2V/DDTbzySsu6wARAQABiQIfBBgBCgAJBQJK tA7pAhsMAAoJEBDAHFovYFnnLe0P/i34oK5cE2LlqUEITEcTO94x1EX0UmtKokRfQ3AYWK8X eFD8cmSty72hMkL+1c0V//4Qc53SUyLIWXk8FKWF7hdL3zyuBqlRb55721CYC35GA/jR90p0 k1vr701gaat2cNTOVC0/6H9cE5yYXT+zMr9TSiKCDwONhhSbmAJZc6X0fgsmCD7I5xUI5Vri hN/Wx0CZBtrXGUyE4hgFaYSGptZmkY5Ln1e+nI185Bda7bpLwcAIGrI9nYtVXgf71ybGKdPP tFfXIoPXuctn99M7NnWBhNuGDms2YWkOC7eeWBTxKkZDWR3vRmRy52B6GxR7USk/KXs7yqGP kfT/c4CZFfOurZUXXuC3PvOme0DQmqwExtJormoG4Fy6suEFPrfhYMigTy7kSbVTCOBMjQLH +U/FFNshvg9+M/ZvaKT+0lpRvBSuG5ngsC0bO0xWsXhb6qfH2h53g4VcwFvCBL5IfqgAeUbC nGGHNcGWpmwdeb7D7ahrNZSHEUUYR7lTbjkYS01/QDOcEwNZOqDRIJUQOOUq35721VeROkdh ZmMZtFlsQeQJsWoqGrQo/kEYicVlMVOgjmOOzOa5fRb/IqlGlBn4a4me3hWthLLtMy+OOEim 6ENjntVTBQiTP/YqrxWDbCkaD7b2e9wY5N3JlRxMIQHfcHaND3PRdQSn7oHYXmJl
  • Delivered-to: jakartaee-tck-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/jakartaee-tck-dev/>
  • List-help: <mailto:jakartaee-tck-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev>, <mailto:jakartaee-tck-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jakartaee-tck-dev>, <mailto:jakartaee-tck-dev-request@eclipse.org?subject=unsubscribe>
  • User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

-1 for removing the no super-setting rule.

Mark


The speculative development
On 27/01/2021 14:35, Scott Marlow wrote:
> 
> On 1/27/21 4:13 AM, Steve Millidge (Payara) wrote:
>>
>> I was wondering about the no super-setting rule. How will we do “code
>> first” spec development for Jakarta EE 10 with a no super-setting rule.
>>
> Historically, we use the no super-setting rule to ensure that
> applications are compatible between multiple implementations.  While the
> goal of issues/156 [2] is to remove Java SE class information from TCK
> signature testing, we could consider other changes. 
> 
> IMO, this is the right mailing list for expressing opinions about
> relaxing/removing rules or tightening them up (and expressing the "why"). 
> 
> Of course you can change your mind, but for now, I am going to start
> tracking opinions such as yours in this email thread for possible later
> collection.
> 
> Steve Millidge vote: +1 for removing/relaxing `no super-setting` rule.
> 
> 
>>  
>>
>> For example if we want to get early access spec implementations out in
>> the open in Payara for feedback we would then cease to be a Compatible
>> Implementation of Jakarta EE as we would fail the signature test?
>>
> In a best case, there is one or more early access spec implementation
> that adds the same early (e.g. still changing) API methods. 
> 
> In a worst case, there are multiple early access spec implementations
> that may add the same early API methods but also add others that they
> think should be included but do not get added to the specification.  The
> problem here is with adding vendor specific extension methods/fields,
> which if used by applications, reduce compatibility between implementations.
> 
> IMO, if we went down this path of removing/relaxing the `no
> super-setting` rule, we would need to define other rules to ensure that
> vendor extension methods/fields are fair game to be redefined by the
> underlying specification in the future.  There is probably much more to
> consider as well. 
> 
> Regarding the how we do "code first" spec development for Jakarta EE 10
> with a no super-setting rule, that is a very good question.  IMO, we
> really need to consider the compatibility impact as mentioned above but
> if we kept the no super-setting rule, all EE 10 implementations need to
> change their spec implementations to match the final Jakarta EE 10
> signatures, before they can consider their EE 10 implementation to be
> compatible.  In other words, you can make any API change during
> development but when the EE 10 specifications are complete and final,
> all implementations need to match the final EE 10 signatures.
> 
> The above are not really my opinions, I will try to respond without
> expressing my opinions at this time. 
> 
> Scott
> 
>>
>>  
>>
>> Does the EFSP etc. require a no super-setting rule?
>>
>>  
>>
>> Thanks
>>
>>
>> Steve
>>
>>  
>>
>> *From:*jakartaee-tck-dev <jakartaee-tck-dev-bounces@xxxxxxxxxxx> *On
>> Behalf Of *Scott Marlow
>> *Sent:* 27 January 2021 03:08
>> *To:* jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
>> *Subject:* [jakartaee-tck-dev] What are the requirements for TCK
>> Signature testing in the future?
>>
>>  
>>
>> Hi,
>>
>> Even if you do not want to get your hands dirty with the JDK SigTest
>> project at this time, it would be awesome to hear some feedback on
>> what might be the minimal requirements for signature testing.  More
>> specifically, I spent some time reading the SigTest source with issue
>> [2] in mind and noted some (possible) minimal requirements today [3].
>>
>> IMO, the underlying goal of [2] is to allow the TCK Signature tests to
>> be targeted for a base Java SE version but also for the signatures
>> tests  be possible to pass on newer Java SE versions.  Below is a copy
>> of comment [3]:
>>
>> "
>>
>> Some desired goals for what I am trying to accomplish for this issue:
>>
>> 1.      Do verify that the super class name doesn't change but do not
>> verify the super class contents (e.g. no JDK class content checking).
>>
>> 2.      Do verify that each annotation name is as expected but do not
>> verify the actual annotation signature.
>>
>> 3.      Do verify each public class method/field signature.
>>
>> 4.      Do fail if any public class method/field are added (for no
>> super-setting rule).
>>
>> 5.      Do fail if any public class method/field are removed (for no
>> sub-setting rule).
>>
>> 6.      To be clear, any JDK class referenced by name in the Jakarta
>> EE SPEC API class will still be verified to still reference the same
>> class name
>>
>> "
>>
>> I am at the point of hacking on some JDK SigTest changes [4] and need
>> to work through some issues that I am hitting with the Java SE 8
>> signatures running on a new Java SE version.  Now that I just have a
>> (rough) overview of the SigTest code, I would like to start sharing
>> with the experience of making this change, so others can learn as
>> well.  Perhaps we can record a video of a `SigTest` code walk through
>> soon.
>>
>> If anyone does have feedback on what the minimal TCK signature checks
>> need to be, that would be good to share.
>>
>> I would like to point out that we might be able to do better than I
>> described in #2, but that isn't clear yet.
>>
>> If you have feedback that we should still detect sub/super-setting (#4
>> + #5) or that we shouldn't, please share your opinion/comments.
>>
>> Thanks,
>>
>> Scott
>> [1] https://wiki.openjdk.java.net/display/CodeTools/sigtest
>> [2] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156 "Need
>> improved signature test tool that doesn't include JDK signatures"
>> [3]
>> https://github.com/eclipse-ee4j/jakartaee-tck/issues/156#issuecomment-767836958
>> [4] https://github.com/scottmarlow/sigtest/tree/explore_more_changes
>> [5] https://docs.oracle.com/javase/9/docs/api/java/lang/Deprecated.html
>>
>>
>> _______________________________________________
>> jakartaee-tck-dev mailing list
>> jakartaee-tck-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
> 
> _______________________________________________
> jakartaee-tck-dev mailing list
> jakartaee-tck-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
> 



Back to the top