I was not able to run Processing IDE v2 with Java 8 ... I expect you will say that ARM is not your problem
You are right it is not my problem, speak to the Processing developers
and you confirmed NPEs with Java 8, which is a very bad software behavior especially for a piece of code like reusable library this should be
The problem is caused by changes to Processing made within 3.0a6 (rather than being Java 8 related) and as I have said previously...
I have NO intention of changing G4P to work with alpha versions of Processing 3.
In fact the changes being made in PS3 mean that there may not be a simple upgrade path for many existing libraries and tools such as G4P and GUI Builder.
This is NOT the fault of the library/tool authors (including me). The PS developers anticipated some existing contributed libraries and tools to break with PS3 but do not appear to have provided any documentation to assist people like me in updating their software.
I'v been having the same problems on Processing 2.2.1, and I tried the solutions in this thread, even deleting and reinstalling the new G4P 3.5.3 and I am still getting the same problem.
It crashes when I open a new window AND append text to a textarea object too fast. I try appending text every 500ms down to 250ms and it seems to work, but if I go below that point, then the errors start popping up faster as the delay goes down. I seem to get 5 errors in particular
java.lang.NullPointerException at java.awt.font.TextLine.checkCtorArgs(TextLine.java:135)
java.lang.NullPointerException at java.util.LinkedList$ListItr.next(LinkedList.java:891)
java.lang.NullPointerException at g4p_controls.StyledString.getLines(Unknown Source)
java.lang.ArrayIndexOutOfBoundsException: -1 at java.awt.font.CharArrayIterator.previous(CharArrayIterator.java:122)
The last error was rare, but it had the word Delegation, invoke, and Impl or something in it :/
Lines 28-58 in Osc.pde, line 48 actually causes the error
I try appending text every 500ms down to 250ms and it seems to work
The GTextarea control is not designed to append large amounts of text. In fact this control does not remove text when it scrolls up the controls display area so the control becomes unresponsive (slow update speed) when it contains large amount of text. Appending data at every 250ms or faster is eventually likely to encounter a problem.
The solution might be to store the text yourself and then use setText to display it. This way you control the amount of text to display.
Well, I used to use it not in a new window, it was just an object on the main screen and with worked wonderfully for hundreds of lines of debugging info. The 250 - 500ms was testing it, if I put 150ms delay, it usually wont get past 5 lines of text before throwing an NPE error. Any faster than that and usually fails before even 1 line...
The similarity of "in a new window" between my problem and the OP problem is why I posted this issue, I'm certain the problems are related.
By design Processing only provides a single output window. Although it is fairly straight forward to create a second window for a particular sketch, for libraries like G4P that need to provide feature rich generic windows that anyone can include in their sketch it is a nightmare. It means that although secondary GWindows look and behave in a similar manner to the main PS window they are not, so there are some limitations and it appears that you have discovered one.
Answers
AFAIK, lambdas wouldn't work w/ ".pde" files just like
enum
.PDE's pre-processor is not even fully compatible w/ Java 5. 3:-O
@cyberluke
You are right it is not my problem, speak to the Processing developers
The problem is caused by changes to Processing made within 3.0a6 (rather than being Java 8 related) and as I have said previously...
I have NO intention of changing G4P to work with alpha versions of Processing 3.
In fact the changes being made in PS3 mean that there may not be a simple upgrade path for many existing libraries and tools such as G4P and GUI Builder.
This is NOT the fault of the library/tool authors (including me). The PS developers anticipated some existing contributed libraries and tools to break with PS3 but do not appear to have provided any documentation to assist people like me in updating their software.
I'v been having the same problems on Processing 2.2.1, and I tried the solutions in this thread, even deleting and reinstalling the new G4P 3.5.3 and I am still getting the same problem.
It crashes when I open a new window AND append text to a textarea object too fast. I try appending text every 500ms down to 250ms and it seems to work, but if I go below that point, then the errors start popping up faster as the delay goes down. I seem to get 5 errors in particular
java.lang.NullPointerException at java.awt.font.TextLine.checkCtorArgs(TextLine.java:135)
java.lang.NullPointerException at java.util.LinkedList$ListItr.next(LinkedList.java:891)
java.lang.NullPointerException at g4p_controls.StyledString.getLines(Unknown Source)
java.lang.ArrayIndexOutOfBoundsException: -1 at java.awt.font.CharArrayIterator.previous(CharArrayIterator.java:122)
The last error was rare, but it had the word Delegation, invoke, and Impl or something in it :/
Lines 28-58 in Osc.pde, line 48 actually causes the error
Lines 14-21 in Debug.pde
Here is a download link to my code mediafire.com/download/21b2ke8c8q2qn1k/Osc.zip
The GTextarea control is not designed to append large amounts of text. In fact this control does not remove text when it scrolls up the controls display area so the control becomes unresponsive (slow update speed) when it contains large amount of text. Appending data at every 250ms or faster is eventually likely to encounter a problem.
The solution might be to store the text yourself and then use
setText
to display it. This way you control the amount of text to display.Well, I used to use it not in a new window, it was just an object on the main screen and with worked wonderfully for hundreds of lines of debugging info. The 250 - 500ms was testing it, if I put 150ms delay, it usually wont get past 5 lines of text before throwing an NPE error. Any faster than that and usually fails before even 1 line...
The similarity of "in a new window" between my problem and the OP problem is why I posted this issue, I'm certain the problems are related.
I didn't realise it is in a new GWindow.
By design Processing only provides a single output window. Although it is fairly straight forward to create a second window for a particular sketch, for libraries like G4P that need to provide feature rich generic windows that anyone can include in their sketch it is a nightmare. It means that although secondary GWindows look and behave in a similar manner to the main PS window they are not, so there are some limitations and it appears that you have discovered one.