Background. The file Property.java contains an array constants of objects. It contains all the literals that appear explicitly in the topl properties. In addition, it contains several other strings: (1) the error messages and (2) descriptive names for the events. These additional strings are here so that the format of Property.text is kept as simple as possible. See for example issue #23.
Problem. However, if there are many events we run again into the limit on bytecode size. (Jules told me this a while ago, but I was hoping we won't run into this limitation. I did run into it. I wanted to figure out which parts of eclipse are exercised by the dacapo benchmark so I wrote a property that fails on all events from org.eclipse.core.)
Possible solution. It is inevitable that we need to store strings (2) outside of the Java file. One solution would be to revert my commit that fixes #23. Still, I'd prefer a solution for handling strings that obviously can't break the parsing of Property.text. (You know, there are two types of programs: those that are obviously OK, and those with no obvious bugs.)
Background. The file Property.java contains an array
constantsof objects. It contains all the literals that appear explicitly in the topl properties. In addition, it contains several other strings: (1) the error messages and (2) descriptive names for the events. These additional strings are here so that the format of Property.text is kept as simple as possible. See for example issue #23.Problem. However, if there are many events we run again into the limit on bytecode size. (Jules told me this a while ago, but I was hoping we won't run into this limitation. I did run into it. I wanted to figure out which parts of eclipse are exercised by the dacapo benchmark so I wrote a property that fails on all events from
org.eclipse.core.)Possible solution. It is inevitable that we need to store strings (2) outside of the Java file. One solution would be to revert my commit that fixes #23. Still, I'd prefer a solution for handling strings that obviously can't break the parsing of Property.text. (You know, there are two types of programs: those that are obviously OK, and those with no obvious bugs.)