{"id":{"repo_id":"uiuc","oai_identifier":"oai:www.ideals.illinois.edu:2142/108343"},"canonical_url":"https://search.dev.ndltd.org/etd/uiuc/oai:www.ideals.illinois.edu:2142/108343","repository":{"repo_id":"uiuc","name":"University of Illinois - Urbana-Champaign","base_url":"https://www.ideals.illinois.edu/oai-pmh"},"display":{"title":"Automated fixing of wrong assumptions on underdetermined specifications","abstract":"Software specifications assist in the implementation of software by stating expected software behavior. Many software specifications are deterministic, i.e., the software produces the same output for the same input. However, some specifications are underdetermined, meaning that the software may produce different outputs given the same input. Underdetermined specifications are not uncommon because they can offer some advantages over deterministic ones. For instance, underdetermined specifications can allow for optimization as developers can be more flexible when conducting speed optimization. We encounter potential problems when deterministic implementations produce different outputs. For example, even though the Java standard library does not specify the order of elements returned by method getDeclaredFields, prevailing implementations, like Oracle JDK 1.8, return fields in the order as they are listed in the class file (which is itself the order in which they are in the source file when using the standard javac compiler). There is no reason to expect the implementation will not change because the specifications allow flexibility, and popular vendors have historically changed the implementations of several widely used library methods. Unfortunately, software library users may write code that relies on a specific implementation rather than on the specification, e.g., assuming mistakenly that the order of elements cannot change in the future. If users write software tests that involve methods with underdetermined specifications, those tests can therefore produce unexpectedly non-deterministic outputs, meaning that tests can intermittently fail or pass without changing the production and test code (but changing the library code). Prior work proposed the NonDex approach to proactively detect such wrong assumptions in the production and test code. The goal of this thesis is to propose automated code changes that help resolve these issues by either making the output deterministic or making the test assertion order-agnostic. We present a novel approach, called DexFix, to fix wrong assumptions on underdetermined software specifications in an automated way. To demonstrate these efforts, we run the NonDex tool on 200 open-source Java projects and detect 275 tests that fail due to wrong assumptions. We find that the majority of failures are based on HashMap/HashSet class iterations and the getDeclaredFields method. We provide several new automated fix strategies that can fix these violations in both the production and test code, which are implemented in the DexFix tool. Our experiments show that DexFix proposes fixes for 101 tests from our 275 tests. We have reported fixes for 84 tests to the developers as GitHub pull requests: 57 have been merged, with only 2 rejected, and the remaining are pending.","abstract_html":"Software specifications assist in the implementation of software by stating expected software behavior. Many software specifications are deterministic, i.e., the software produces the same output for the same input. However, some specifications are underdetermined, meaning that the software may produce different outputs given the same input. Underdetermined specifications are not uncommon because they can offer some advantages over deterministic ones. For instance, underdetermined specifications can allow for optimization as developers can be more flexible when conducting speed optimization. We encounter potential problems when deterministic implementations produce different outputs. For example, even though the Java standard library does not specify the order of elements returned by method getDeclaredFields, prevailing implementations, like Oracle JDK 1.8, return fields in the order as they are listed in the class file (which is itself the order in which they are in the source file when using the standard javac compiler). There is no reason to expect the implementation will not change because the specifications allow flexibility, and popular vendors have historically changed the implementations of several widely used library methods. Unfortunately, software library users may write code that relies on a specific implementation rather than on the specification, e.g., assuming mistakenly that the order of elements cannot change in the future. If users write software tests that involve methods with underdetermined specifications, those tests can therefore produce unexpectedly non-deterministic outputs, meaning that tests can intermittently fail or pass without changing the production and test code (but changing the library code). Prior work proposed the NonDex approach to proactively detect such wrong assumptions in the production and test code. The goal of this thesis is to propose automated code changes that help resolve these issues by either making the output deterministic or making the test assertion order-agnostic. We present a novel approach, called DexFix, to fix wrong assumptions on underdetermined software specifications in an automated way. To demonstrate these efforts, we run the NonDex tool on 200 open-source Java projects and detect 275 tests that fail due to wrong assumptions. We find that the majority of failures are based on HashMap/HashSet class iterations and the getDeclaredFields method. We provide several new automated fix strategies that can fix these violations in both the production and test code, which are implemented in the DexFix tool. Our experiments show that DexFix proposes fixes for 101 tests from our 275 tests. We have reported fixes for 84 tests to the developers as GitHub pull requests: 57 have been merged, with only 2 rejected, and the remaining are pending.","abstract_has_math":false,"creators":["Zhang, Peilun"],"institution":"University of Illinois at Urbana-Champaign","degree_name":"M.S.","degree_level":"Thesis","degree_discipline":"Computer Science","degree_department":null,"school":null,"contributors":["Marinov, Darko","Stodden, Victoria"],"advisors":[],"committee_chairs":[],"committee_members":[],"year":2020,"date_issued":"2020-08-27T00:51:32Z","date_published":"2020-08-27T00:51:32Z","updated_at":"2026-07-22T22:24:48Z","subjects":["Software testing","Regression testing","Flaky test"],"languages":["en"],"rights":["Copyright 2020 Peilun Zhang"],"rights_urls":[],"identifier_entries":[]},"links":{"outbound_url":"http://hdl.handle.net/2142/108343","outbound_label":"Handle","outbound_source":"dc:identifier"},"metadata_groups":[{"id":"people","label":"People","entries":[{"key":"dc:contributor","label":"Contributor","values":["Marinov, Darko","Stodden, Victoria"]},{"key":"dc:creator","label":"Author","values":["Zhang, Peilun"]}]},{"id":"academic_context","label":"Academic Context","entries":[{"key":"dc:date","label":"Dc Date","values":["2020-08-27T00:51:32Z","2022-08-27T00:51:40Z","2020-05-12","2020-05"]},{"key":"dc:type","label":"Dc Type","values":["text","Thesis"]},{"key":"thesis:degree_discipline","label":"Discipline","values":["Computer Science"]},{"key":"thesis:degree_level","label":"Degree Level","values":["Thesis"]},{"key":"thesis:degree_name","label":"Degree Name","values":["M.S."]},{"key":"thesis:institution_name","label":"Thesis Institution Name","values":["University of Illinois at Urbana-Champaign"]}]},{"id":"subjects_keywords","label":"Subjects and Keywords","entries":[{"key":"dc:subject","label":"Dc Subject","values":["Software testing","Regression testing","Flaky test"]}]},{"id":"language_rights","label":"Language and Rights","entries":[{"key":"dc:language","label":"Dc Language","values":["en"]},{"key":"dc:rights","label":"Dc Rights","values":["Copyright 2020 Peilun Zhang"]}]},{"id":"identifiers","label":"Identifiers","entries":[{"key":"dc:identifier","label":"Identifier","values":["http://hdl.handle.net/2142/108343"]}]},{"id":"additional","label":"Additional Metadata","entries":[{"key":"dc:description","label":"Description","values":["Software specifications assist in the implementation of software by stating expected software behavior. Many software specifications are deterministic, i.e., the software produces the same output for the same input. However, some specifications are underdetermined, meaning that the software may produce different outputs given the same input. Underdetermined specifications are not uncommon because they can offer some advantages over deterministic ones. For instance, underdetermined specifications can allow for optimization as developers can be more flexible when conducting speed optimization. We encounter potential problems when deterministic implementations produce different outputs. For example, even though the Java standard library does not specify the order of elements returned by method getDeclaredFields, prevailing implementations, like Oracle JDK 1.8, return fields in the order as they are listed in the class file (which is itself the order in which they are in the source file when using the standard javac compiler). There is no reason to expect the implementation will not change because the specifications allow flexibility, and popular vendors have historically changed the implementations of several widely used library methods. Unfortunately, software library users may write code that relies on a specific implementation rather than on the specification, e.g., assuming mistakenly that the order of elements cannot change in the future. If users write software tests that involve methods with underdetermined specifications, those tests can therefore produce unexpectedly non-deterministic outputs, meaning that tests can intermittently fail or pass without changing the production and test code (but changing the library code). Prior work proposed the NonDex approach to proactively detect such wrong assumptions in the production and test code. The goal of this thesis is to propose automated code changes that help resolve these issues by either making the output deterministic or making the test assertion order-agnostic. We present a novel approach, called DexFix, to fix wrong assumptions on underdetermined software specifications in an automated way. To demonstrate these efforts, we run the NonDex tool on 200 open-source Java projects and detect 275 tests that fail due to wrong assumptions. We find that the majority of failures are based on HashMap/HashSet class iterations and the getDeclaredFields method. We provide several new automated fix strategies that can fix these violations in both the production and test code, which are implemented in the DexFix tool. Our experiments show that DexFix proposes fixes for 101 tests from our 275 tests. We have reported fixes for 84 tests to the developers as GitHub pull requests: 57 have been merged, with only 2 rejected, and the remaining are pending.","Submission published under a 24 month embargo labeled 'Closed Access', the embargo will last until 2022-05-01","The student, Peilun Zhang, accepted the attached license on 2020-05-11 at 13:58.","The student, Peilun Zhang, submitted this Thesis for approval on 2020-05-11 at 14:18.","This Thesis was approved for publication on 2020-05-12 at 15:53.","DSpace SAF Submission Ingestion Package generated from Vireo submission #15327 on 2020-08-25 at 17:44:19","Made available in DSpace on 2020-08-27T00:51:32Z (GMT). No. of bitstreams: 2 ZHANG-THESIS-2020.pdf: 251202 bytes, checksum: fb1331b85e26b9756559c5c5e54cbe97 (MD5) LICENSE.txt: 4209 bytes, checksum: 715ce4d9f9161ef8e5199618ae689349 (MD5) Previous issue date: 2020-05-12","Embargo set by: Seth Robbins for item 115958 Lift date: 2022-08-27T00:51:40Z Reason: Author requested closed access (OA after 2yrs) in Vireo ETD system","Author requested closed access (OA after 2yrs) in Vireo ETD system","Limited"]},{"key":"dc:format","label":"Dc Format","values":["application/pdf"]},{"key":"dc:title","label":"Title","values":["Automated fixing of wrong assumptions on underdetermined specifications"]}]}],"canonical_facts":{"dc:contributor":["Marinov, Darko","Stodden, Victoria"],"dc:creator":["Zhang, Peilun"],"dc:date":["2020-08-27T00:51:32Z","2022-08-27T00:51:40Z","2020-05-12","2020-05"],"dc:description":["Software specifications assist in the implementation of software by stating expected software behavior. Many software specifications are deterministic, i.e., the software produces the same output for the same input. However, some specifications are underdetermined, meaning that the software may produce different outputs given the same input. Underdetermined specifications are not uncommon because they can offer some advantages over deterministic ones. For instance, underdetermined specifications can allow for optimization as developers can be more flexible when conducting speed optimization. We encounter potential problems when deterministic implementations produce different outputs. For example, even though the Java standard library does not specify the order of elements returned by method getDeclaredFields, prevailing implementations, like Oracle JDK 1.8, return fields in the order as they are listed in the class file (which is itself the order in which they are in the source file when using the standard javac compiler). There is no reason to expect the implementation will not change because the specifications allow flexibility, and popular vendors have historically changed the implementations of several widely used library methods. Unfortunately, software library users may write code that relies on a specific implementation rather than on the specification, e.g., assuming mistakenly that the order of elements cannot change in the future. If users write software tests that involve methods with underdetermined specifications, those tests can therefore produce unexpectedly non-deterministic outputs, meaning that tests can intermittently fail or pass without changing the production and test code (but changing the library code). Prior work proposed the NonDex approach to proactively detect such wrong assumptions in the production and test code. The goal of this thesis is to propose automated code changes that help resolve these issues by either making the output deterministic or making the test assertion order-agnostic. We present a novel approach, called DexFix, to fix wrong assumptions on underdetermined software specifications in an automated way. To demonstrate these efforts, we run the NonDex tool on 200 open-source Java projects and detect 275 tests that fail due to wrong assumptions. We find that the majority of failures are based on HashMap/HashSet class iterations and the getDeclaredFields method. We provide several new automated fix strategies that can fix these violations in both the production and test code, which are implemented in the DexFix tool. Our experiments show that DexFix proposes fixes for 101 tests from our 275 tests. We have reported fixes for 84 tests to the developers as GitHub pull requests: 57 have been merged, with only 2 rejected, and the remaining are pending.","Submission published under a 24 month embargo labeled 'Closed Access', the embargo will last until 2022-05-01","The student, Peilun Zhang, accepted the attached license on 2020-05-11 at 13:58.","The student, Peilun Zhang, submitted this Thesis for approval on 2020-05-11 at 14:18.","This Thesis was approved for publication on 2020-05-12 at 15:53.","DSpace SAF Submission Ingestion Package generated from Vireo submission #15327 on 2020-08-25 at 17:44:19","Made available in DSpace on 2020-08-27T00:51:32Z (GMT). No. of bitstreams: 2 ZHANG-THESIS-2020.pdf: 251202 bytes, checksum: fb1331b85e26b9756559c5c5e54cbe97 (MD5) LICENSE.txt: 4209 bytes, checksum: 715ce4d9f9161ef8e5199618ae689349 (MD5) Previous issue date: 2020-05-12","Embargo set by: Seth Robbins for item 115958 Lift date: 2022-08-27T00:51:40Z Reason: Author requested closed access (OA after 2yrs) in Vireo ETD system","Author requested closed access (OA after 2yrs) in Vireo ETD system","Limited"],"dc:format":["application/pdf"],"dc:identifier":["http://hdl.handle.net/2142/108343"],"dc:language":["en"],"dc:rights":["Copyright 2020 Peilun Zhang"],"dc:subject":["Software testing","Regression testing","Flaky test"],"dc:title":["Automated fixing of wrong assumptions on underdetermined specifications"],"dc:type":["text","Thesis"],"thesis:degree_discipline":["Computer Science"],"thesis:degree_level":["Thesis"],"thesis:degree_name":["M.S."],"thesis:institution_name":["University of Illinois at Urbana-Champaign"]},"updated_at":"2026-07-22T22:24:48Z"}