Uploaded image for project: 'Code Tools'
  1. Code Tools
  2. CODETOOLS-7902401

provide (better) access to TestResultTable FilterObserver


    • Type: Enhancement
    • Status: New
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: tools
    • Labels:


      This is the JT Harness parts of a proposal for CODETOOLS-7902279.

      (From private email)

      It is conceptually wrong for an iterator, such as TRT_Iterator, to be in the business of mutating the
      underlying collection, such as the TestResultTable. It is one thing for an iterator to facilitate updates,
      (see the limited set of operations available during iterations in the collections API), but it is pretty
      bad for the iterator itself to do the mutation, even if it is guarded by an external control.

      It is pretty ugly to use persistent data, such as JavaTest Preferences to control whether or not the
      iteration should update the TestResultTable. At one point, [someone] justified this by saying it was OK
      because the preferences were not actually saved, but I found the following line in javatest.Report
      which undermines that claim:

                 writePrefs(s); // write settings to Preferences

      It also seems to cross an abstraction boundary to use a preference in the ".exec" namespace,
      which one might presume to be used by the `com.sun.javatest.exec` package.

      It is also weird to be using this back-door mechanism when there is already a first-class mechanism
      (FilterObserver) which can be notified when a test is rejected by a filter. This would seem to be a
      better way to hook into the iteration such that the TestResultTable can be updated with custom
      "notRun" status objects, giving the appropriate reason.

      How to fix this, without breaking too much stuff?

      The goal here is to not break existing usage in JavaTest (i.e. JCK) but to not be forced into
      that style of usage in jtreg. With that in mind, even though I think the direct manipulation
      of the TestResultTable in TRT_Iterator.wouldAccept is wrong, I think that inherently changing
      that is too much worth. What we should fix is when that functionality is enabled. In general,
      I think it should be a member property of each instance of TRT_Iterator to determine
      whether this behavior is enabled. That implies the member should either be initialized
      in a new constructor, or via a setter method. Personally, I think a new constructor
      is better so that `recordRejectTR` can be a final field, initialized by the preference in
      the existing constructor or via the use of a new constructor.




            • Assignee:
              dbessono Dmitry Bessonov
              jjg Jonathan Gibbons
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: