Loading ...
Sorry, an error occurred while loading the content.

Re: [pcgen_developers] OpenJDK 1.7

Expand Messages
  • James Dempsey
    Hi Stefan, On 7/01/2012 12:50 PM Stefan Radermacher wrote ... Ok, that s a step forward. ... Could you raise a bug for that one please? ... Could it be related
    Message 1 of 17 , Jan 6, 2012
    View Source
    • 0 Attachment
      Hi Stefan,

      On 7/01/2012 12:50 PM Stefan Radermacher wrote
      > On 07.01.2012 02:07, James Dempsey wrote:
      >> It was one of those problems that happen the first time you started it,
      >> so good to catch now.
      > Ok this works much better now, but I still get an NPE when closing the
      > prefs dialog, but this time the dialog actually closes.
      Ok, that's a step forward.

      > And I noticed another thing that might not be apparent to you: even
      > though the language preferences is set to English "right from the start)
      > I' getting lots of UI strings in German.
      Could you raise a bug for that one please?
      > Here's the stack trace when closing the prefs dialog:
      >
      > 02:47:17.339 SEVERE AWT-EventQueue-1 PCGen_Frame1:2940 Uncaught error -
      > ignoring
      > java.lang.NullPointerException
      > at
      > javax.swing.DefaultListCellRenderer.getListCellRendererComponent(DefaultListCellRenderer.java:103)
      > at
      > javax.swing.plaf.basic.BasicComboBoxUI.getDefaultSize(BasicComboBoxUI.java:1283)
      > at
      > javax.swing.plaf.basic.BasicComboBoxUI.getDisplaySize(BasicComboBoxUI.java:1354)
      > at
      > javax.swing.plaf.basic.BasicComboBoxUI.getMinimumSize(BasicComboBoxUI.java:903)
      > at
      > javax.swing.plaf.metal.MetalComboBoxUI.getMinimumSize(MetalComboBoxUI.java:332)
      > at javax.swing.JComponent.getMinimumSize(JComponent.java:1714)
      > at javax.swing.BoxLayout.checkRequests(BoxLayout.java:463)
      > at javax.swing.BoxLayout.preferredLayoutSize(BoxLayout.java:281)
      > at
      > javax.swing.JToolBar$DefaultToolBarLayout.preferredLayoutSize(JToolBar.java:752)
      > at java.awt.Container.preferredSize(Container.java:1599)
      > at java.awt.Container.getPreferredSize(Container.java:1584)
      > at javax.swing.JComponent.getPreferredSize(JComponent.java:1636)
      > at java.awt.BorderLayout.layoutContainer(BorderLayout.java:798)
      > at java.awt.Container.layout(Container.java:1421)
      > at java.awt.Container.doLayout(Container.java:1410)
      > at java.awt.Container.validateTree(Container.java:1507)
      > at java.awt.Container.validateTree(Container.java:1513)
      > at java.awt.Container.validateTree(Container.java:1513)
      > at java.awt.Container.validate(Container.java:1480)
      > at
      > javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:670)
      > at
      > javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1635)
      > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
      > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641)
      > at java.awt.EventQueue.access$000(EventQueue.java:84)
      > at java.awt.EventQueue$1.run(EventQueue.java:602)
      > at java.awt.EventQueue$1.run(EventQueue.java:600)
      > at java.security.AccessController.doPrivileged(Native Method)
      > at
      > java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
      > at java.awt.EventQueue.dispatchEvent(EventQueue.java:611)
      > at
      > pcgen.gui.PCGen_Frame1$WaitCursorEventQueue.dispatchEvent(PCGen_Frame1.java:2935)
      > at
      > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
      > at
      > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
      > at
      > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
      > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
      > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
      > at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
      >

      Could it be related to http://jira.pcgen.org/browse/CODE-1141 ?

      Cheers,
      James.
    • Stefan Radermacher
      ... I will do that tomorrow. Time for bed now. :) ... Yes, it looks similar. I noticed that when opening the prefs for the first time, no LnF is actually
      Message 2 of 17 , Jan 6, 2012
      View Source
      • 0 Attachment
        On 07.01.2012 03:14, James Dempsey wrote:
        > > And I noticed another thing that might not be apparent to you: even
        > > though the language preferences is set to English "right from the start)
        > > I' getting lots of UI strings in German.
        > Could you raise a bug for that one please?

        I will do that tomorrow. Time for bed now. :)

        > Could it be related to http://jira.pcgen.org/browse/CODE-1141 ?

        Yes, it looks similar. I noticed that when opening the prefs for the
        first time, no LnF is actually selected. If an LnF is actually selected,
        the dialog closes without an NPE.

        Regards,
        Stefan.
      • Martijn Verburg
        Hi Both, Hi Stefan, ... Absolutely, let me recreate it here with a few variations of IDE and Java and I ll fire something acros to the core-lib team. PCGen -
        Message 3 of 17 , Jan 7, 2012
        View Source
        • 0 Attachment
          Hi Both,

          Hi Stefan,

          On 7/01/2012 5:31 AM Stefan Radermacher wrote


          On 06.01.2012 18:36, Martijn Verburg wrote:
          
          Error?
          
          Here's the complete compile log: http://pastebin.com/8jQDWkiA
          
          It looks like there is some sort of mix-up between pcgen.cdom.enumeration.Type and java.awt.Window.Type. See the example from ChooseSpellDialog.java below.

          1.     [javac] /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/ChooseSpellDialog.java:473: error: incompatible types
          2.     [javac]                             itemType = EqBuilder.validEqTypes[eqType];
          3.     [javac]                                                              ^
          4.     [javac]   required: java.awt.Window.Type
          5.     [javac]   found:    pcgen.cdom.enumeration.Type
          6.     [javac] /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/ChooseSpellDialog.java:481:error: method isAllowed in class Spell cannot be applied to given types;
          7.     [javac]             return aSpell.isAllowed(itemType);
          8.     [javac]                          ^
          9.     [javac]   required: pcgen.cdom.enumeration.Type
          10.     [javac]   found: java.awt.Window.Type
          11.     [javac]   reason: actual argument java.awt.Window.Type cannot be converted to pcgen.cdom.enumeration.Type by method invocation conversion
          I'd say there is a bug in the compiler where it is getting mixed up between the two enumerations (actually ours is a class) with the name of Type. We don't directly reference the Window class in that file but do pull in a few other awt classes. Perhaps one of those has a static reference to their enumeration which is overwriting ours?

          The other three reported errors are the same issue:

          1. [javac] /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/editor/EditorMainForm.java:592: error: cannot find symbol
          2.     [javac]             thisPObject.addToListFor(ListKey.TYPE, Type.CUSTOM);
          3.     [javac]                                                        ^
          4.     [javac]   symbol:   variable CUSTOM
          5.     [javac]   location: class Type
          6.     [javac] /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/editor/EditorMainForm.java:2167: error: incompatible types
          7.     [javac]                             for (Type t : wp.getTrueTypeList(false))
          8.     [javac]                                                             ^
          9.     [javac]   required: java.awt.Window.Type
          10.     [javac]   found:    pcgen.cdom.enumeration.Type
          11.     [javac] /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/editor/EditorMainForm.java:2351: error: incompatible types
          12.     [javac]                             for (Type type : aSkill.getTrueTypeList(false))
          13.     [javac]                                                                    ^
          14.     [javac]   required: java.awt.Window.Type
          15.     [javac]   found:    pcgen.cdom.enumeration.Type
          I tried this out with jdk1.7.0_02 and I get the same error compiling via ant and via Eclipse.  There doesn't seem an obvious workaround as our import list isn't being respected. I think this might need to be passed to the Java team as an error. Kar would you have contacts to do that?

          Absolutely, let me recreate it here with a few variations of IDE and Java and I'll fire something acros to the core-lib team.

          PCGen - fixing bugs in Java and Eclipse ;-)

          K
        • Martijn Verburg
          OK, I ve reproduced and will file a bug report with them. In the mean time you can use the fully qualified package when declaring the type, e.g.
          Message 4 of 17 , Jan 12, 2012
          View Source
          • 0 Attachment
            OK, I've reproduced and will file a bug report with them. In the mean
            time you can use the fully qualified package when declaring the type,
            e.g.

            thisPObject.addToListFor(ListKey.TYPE, Type.CUSTOM);

            -->

            thisPObject.addToListFor(ListKey.TYPE, pcgen.cdom.enumeration.Type.CUSTOM);

            K

            On 7 January 2012 11:34, Martijn Verburg <martijnverburg@...> wrote:
            > Hi Both,
            >
            >> Hi Stefan,
            >>
            >> On 7/01/2012 5:31 AM Stefan Radermacher wrote
            >>
            >>
            >> On 06.01.2012 18:36, Martijn Verburg wrote:
            >>
            >> Error?
            >>
            >> Here's the complete compile log: http://pastebin.com/8jQDWkiA
            >>
            >> It looks like there is some sort of mix-up between
            >> pcgen.cdom.enumeration.Type and java.awt.Window.Type. See the example from
            >> ChooseSpellDialog.java below.
            >>
            >>     [javac]
            >> /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/ChooseSpellDialog.java:473:
            >> error: incompatible types
            >>     [javac]                             itemType =
            >> EqBuilder.validEqTypes[eqType];
            >>     [javac]                                                              ^
            >>     [javac]   required: java.awt.Window.Type
            >>     [javac]   found:    pcgen.cdom.enumeration.Type
            >>     [javac]
            >> /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/ChooseSpellDialog.java:481:
            >> error: method isAllowed in class Spell cannot be applied to given types;
            >>     [javac]             return aSpell.isAllowed(itemType);
            >>     [javac]                          ^
            >>     [javac]   required: pcgen.cdom.enumeration.Type
            >>     [javac]   found: java.awt.Window.Type
            >>     [javac]   reason: actual argument java.awt.Window.Type cannot be
            >> converted to pcgen.cdom.enumeration.Type by method invocation conversion
            >>
            >> I'd say there is a bug in the compiler where it is getting mixed up
            >> between the two enumerations (actually ours is a class) with the name of
            >> Type. We don't directly reference the Window class in that file but do pull
            >> in a few other awt classes. Perhaps one of those has a static reference to
            >> their enumeration which is overwriting ours?
            >>
            >> The other three reported errors are the same issue:
            >>
            >> [javac]
            >> /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/editor/EditorMainForm.java:592:
            >> error: cannot find symbol
            >>     [javac]             thisPObject.addToListFor(ListKey.TYPE,
            >> Type.CUSTOM);
            >>     [javac]                                                        ^
            >>     [javac]   symbol:   variable CUSTOM
            >>     [javac]   location: class Type
            >>     [javac]
            >> /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/editor/EditorMainForm.java:2167:
            >> error: incompatible types
            >>     [javac]                             for (Type t :
            >> wp.getTrueTypeList(false))
            >>     [javac]                                                             ^
            >>     [javac]   required: java.awt.Window.Type
            >>     [javac]   found:    pcgen.cdom.enumeration.Type
            >>     [javac]
            >> /data/PCGen/workspace/uisync/code/src/java/pcgen/gui/editor/EditorMainForm.java:2351:
            >> error: incompatible types
            >>     [javac]                             for (Type type :
            >> aSkill.getTrueTypeList(false))
            >>     [javac]
            >>      ^
            >>     [javac]   required: java.awt.Window.Type
            >>     [javac]   found:    pcgen.cdom.enumeration.Type
            >>
            >> I tried this out with jdk1.7.0_02 and I get the same error compiling via
            >> ant and via Eclipse.  There doesn't seem an obvious workaround as our import
            >> list isn't being respected. I think this might need to be passed to the Java
            >> team as an error. Kar would you have contacts to do that?
            >
            >
            > Absolutely, let me recreate it here with a few variations of IDE and Java
            > and I'll fire something acros to the core-lib team.
            >
            > PCGen - fixing bugs in Java and Eclipse ;-)
            >
            > K
          • Stefan Radermacher
            ... Martijn, did you file that bug, and if so, do you have bug tracker link at hand? Regards, Stefan.
            Message 5 of 17 , Feb 10, 2012
            View Source
            • 0 Attachment
              On 12.01.2012 12:00, Martijn Verburg wrote:
              > OK, I've reproduced and will file a bug report with them. In the mean
              > time you can use the fully qualified package when declaring the type,
              > e.g.


              Martijn, did you file that bug, and if so, do you have bug tracker link
              at hand?

              Regards,
              Stefan.
            • Martijn Verburg
              It s still being discussed on the appropriate OpenJDK mailing list, Bug id soon I m hoping! K On Saturday, 11 February 2012, Stefan Radermacher
              Message 6 of 17 , Feb 10, 2012
              View Source
              • 0 Attachment
                It's still being discussed on the appropriate OpenJDK mailing list, Bug id soon I'm hoping!

                K

                On Saturday, 11 February 2012, Stefan Radermacher <radermacher@...> wrote:
                >  
                >
                > On 12.01.2012 12:00, Martijn Verburg wrote:
                >> OK, I've reproduced and will file a bug report with them. In the mean
                >> time you can use the fully qualified package when declaring the type,
                >> e.g.
                >
                > Martijn, did you file that bug, and if so, do you have bug tracker link
                > at hand?
                >
                > Regards,
                > Stefan.
                >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.