Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] ajde unit test failures under IBM JDK 1.3.1 - SOLVED!!

George's detective work narrowed the problem down to an invalid character
encoding used by the scanner. The bad value ("12345") was set in an earlier
test, and despite a full tear-down and recreate of the environment managed
to persist across test suites through the UserPreferenceStore. Since the
order of junit test execution is undefined, this is a behaviour which can
legitimately change across vms.

The fix is to org.aspectj.ajde.ui.internal.UserPreferenceStore, which
previously did not load user prefs from disk when initialised with
"loadPrefs = null", but did save them. I changed the store so that the
variable became "persist" and controlled both loading *and* saving.

This is the small patch:

Index: UserPreferencesStore.java
===================================================================
RCS file:
/home/technology/org.aspectj/modules/ajde/src/org/aspectj/ajde/ui/internal/UserPreferencesStore.java,v
retrieving revision 1.3
diff -u -r1.3 UserPreferencesStore.java
--- UserPreferencesStore.java 30 Apr 2003 02:31:37 -0000    1.3
+++ UserPreferencesStore.java 9 May 2003 09:12:30 -0000
@@ -33,13 +33,15 @@
     public static final String FILE_NAME = "/.ajbrowser";
     private final String VALUE_SEP = ";";
     private Properties properties = new Properties();
+    private boolean persist = true;

      public UserPreferencesStore() {
         this(true);
      }

     public UserPreferencesStore(boolean loadDefault) {
-        if (loadDefault) {
+     persist = loadDefault;
+        if (persist) {
             loadProperties(getPropertiesFilePath());
         }
     }
@@ -123,6 +125,8 @@
         }
      }
     public void saveProperties() {
+     if (!persist) return;
+
         FileOutputStream out = null;
         String path = null;
         try {

This has been commited and included in the rc2 build, under a presumption
of rule 3. If there are any vetos on this change on the list we'll back it
off again.

Cheers,
Adrian.

-- Adrian.
adrian_colyer@xxxxxxxxxx





08 May 2003 21:15
To: George Harley1/UK/IBM@IBMGB
cc: aspectj-dev@xxxxxxxxxxx
From: Jim.Hugunin@xxxxxxxx
Subject: [aspectj-dev] ajde unit test failures under IBM JDK 1.3.1



George and I have been looking into the 6 ajde unit tests that are
currently failing under the IBM-Windows JDK 1.3.1.  This is an IBM internal
JDK version and thus I'm not able to do any testing with that JDK, so my
conclusions are very rough.

1. The ajde unit tests can be extremely confusing when something goes wrong
because they "swallow" most error messages and even exceptions.  As an
example, modify testdata/examples/figures-coverage/all.lst to add an
invalid filename.  Many tests will now fail, but none of them will provide
any clues as to the reason.  These tests would be much more useful if
better debugging message handling could be provided.  I'd suggest that you
(or Mik) try to improve this message handling as a first step.

2. George has observed a null source char[] in the parser (actually
AjScanner) when running these tests on the IBM JDK.  Here's my best guess
as to what could cause this:

a. Incorrect filenames are being produced by AjBuildConfig.  This probably
comes from some subtle difference in the implementation of the File class
in the IBM JDK.  Hopefully addressing issue #1 above could understand where
this is coming from and if it's a real bug or just a test case weakness.

b. This leads AjBuildManager.getCompilationUnits to return units that
correspond to missing files.  You should look at the CompilationUnit[]
produced by this method to see if the CompilationUnit.getContents() method
will return a real file contents.

c. These bad CompilationUnits lead to the null source char[] that you're
seeing.

3. This error only shows up in ajde (and possibly only in the ajde unit
tests) and should be caught gracefully by the better error handling in the
actual compiler.

4. If this error is too hard to track down we shouldn't delay 1.1rc2 for it
since it only shows up in the test suite (we haven't seen it in actual use)
and it only shows up with the IBM JDK 1.3.1 (and if it is a problem for
actual users they can upgrade to the IBM or SUN 1.4 JVMs).

-Jim

PS - George, let me know how this works for you.  I'm still available for a
8:30am PST call tomorrow if you need more help tracking this down.
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
 http://dev.eclipse.org/mailman/listinfo/aspectj-dev



Back to the top