Date   

Re: Win7 Unable to run ant clean / ant realcean

steve young
 

Thanks for spotting Svata,

Steve.


DecoderPro panel cleanup (was: Re: [jmri-developers] Preview: DecoderPro)

Svata Dedic
 

Dne 21. 10. 19 v 12:58 Dave Heap napsal(a):
Note the "in a later phase".
The two phases seem to have morphed into one and that was not my understanding of your original proposal.
OK :) So let's focus on the refactoring first (changed subject to match the content). I'll discuss the "layout" stuff in the original thread.

There were actually TWO of them all the time:
- "just refactoring" (https://github.com/svatoun/JMRI/tree/feature/decoderpro_layout_split)
- "alignment, spacing" (https://github.com/svatoun/JMRI/tree/feature/decoderpro_gridbag_spaces)

_spaces is based on the _split one, all "refactoring" changes should end up in "_split".

Pls. give me a some time (hope today) to cherrypick the bugfixes to the appropriate branch.

Note that it is possible, that the internal API will change as usual when first one of two "users" (new divergent implementations) are written against it.

-Svata


Re: Preview: alignment in gridbag layout

Dave Heap
 

Svata,

On 21 Oct 2019, at 8:17 PM, Svata Dedic <svatopluk.dedic@...> wrote:

Dne 20. 10. 19 v 12:24 Dave Heap napsal(a):
I've managed to make some time to have a quick test of your branches, looking only at the ESU series decoders, and found two very obvious problems:
1) The special ESU Function Map is missing.

Yes, definitely needs more testing.

I've pushed the code because of Bob's request - my intent was to make more obvious the general direction/idea. Since it is a *refactoring* (rather: rewrite), bugs are naturally expected.

The about 4th question (there are more important ones to get answer first!) is:
   "is there anyone willing to help testing ?"
maybe yes, maybe not, maybe on jmri-users mailing list. But I don't want to waste their time before the more important questions have answers.

I've been keeping a close eye on this (and have already put a lot of time into it, more than I should have, given other commitments) but don't want to be responsible for all testing.

But it's not just a case of testing, it's also a case of whether others agree with your idea of what is more readable. I'm not at all convinced about some aspects of your proposal.

But please see below...


2) The special (replacement) Speed Table pane is not rendering correctly.
Thanks.

I compared "Speed table"s .. and (obviously) found some bug: In my case bottom controls (<griditems> enclosed in <grid>) were skipped by refactored code. Is that the same bug you hit ?

Yes, I suspect it's due to incorrect rendering of <griditems> enclosed in a <group> within the <grid>.

I put the fixes into the branch.

Thanks. Will pull them later.


Considering the round-trip time, would you please provide like one-sentence description next time, so I my fixes are better targetted ?

As a personal opinion, on an onscreen side-by-side comparison of current master and your decoderpro_gridbag_spaces branch, I'm afraid I find the readability of the majority of your panes much lower.


Acknowledged. Will elaborate in a separate e-mail; in the meantime, could you please pinpoint - in your opinion - an example + explain (since some preferences may not be obvious / shared) ?

With the caveat below, here is a link to some "before and after" side-by-side screenshots, for general perusal:


However, I believe the goalposts have shifted. Your original proposal was for "DecoderPro panel cleanup", to which Bob responded very positively.

On 9 Oct 2019, at 5:19 PM, Svata Dedic <svatopluk.dedic@...> wrote:

I'd like to refactor the way how PaneProgPane is built up. No UI change intended in this phase, but rather code can be cleaned up.

That was the proposal. Note the "No UI change intended in this phase". We were all keen about that.

Why doing this: in a later phase, I'd like to make _visual_ changes (see below). Any change, or bugfix will be more consistent, if done on 'canonical' code and easier to review.

Note the "in a later phase".

The two phases seem to have morphed into one and that was not my understanding of your original proposal.

Dave



Re: Preview: alignment in gridbag layout

Svata Dedic
 

Dne 20. 10. 19 v 12:24 Dave Heap napsal(a):
I've managed to make some time to have a quick test of your branches, looking only at the ESU series decoders, and found two very obvious problems:
1) The special ESU Function Map is missing.
Yes, definitely needs more testing.

I've pushed the code because of Bob's request - my intent was to make more obvious the general direction/idea. Since it is a *refactoring* (rather: rewrite), bugs are naturally expected.

The about 4th question (there are more important ones to get answer first!) is:
"is there anyone willing to help testing ?"
maybe yes, maybe not, maybe on jmri-users mailing list. But I don't want to waste their time before the more important questions have answers.

2) The special (replacement) Speed Table pane is not rendering correctly.
Thanks.
I compared "Speed table"s .. and (obviously) found some bug: In my case bottom controls (<griditems> enclosed in <grid>) were skipped by refactored code. Is that the same bug you hit ?

I put the fixes into the branch.

Considering the round-trip time, would you please provide like one-sentence description next time, so I my fixes are better targetted ?

As a personal opinion, on an onscreen side-by-side comparison of current master and your decoderpro_gridbag_spaces branch, I'm afraid I find the readability of the majority of your panes much lower.
Acknowledged. Will elaborate in a separate e-mail; in the meantime, could you please pinpoint - in your opinion - an example + explain (since some preferences may not be obvious / shared) ?

-Svata


Re: Win7 Unable to run ant clean / ant realcean

Svata Dedic
 

Dne 21. 10. 19 v 5:09 Bob Jacobsen napsal(a):
The ${tempdir} symbol is set in the project.properties file. Have you made any changes to that?
Apologies; there's IS a trailing space in project.properties. Please remove it (line 49, tempdir=...).

Introduced by my commit #25b80489
Removed all trailing spaces: https://github.com/JMRI/JMRI/pull/7533

-Svata


Re: Win7 Unable to run ant clean / ant realcean

Bob Jacobsen
 

The ${tempdir} symbol is set in the project.properties file. Have you made any changes to that?

Bob

On Oct 20, 2019, at 5:56 PM, steve young via Groups.Io <icklesteve=yahoo.com@groups.io> wrote:

3 weeks ago I had no issues with running command line ant clean or ant realclean, Win 7 64 bit

Since these were last working, I have
Installed Win updates
Updated local JMRI via Github Desktop to latest head of master
Installed NetBeans 11.1

NetBeans clean also produces the exact same error.

Thanks in advance,

Steve.

BUILD FAILED
C:\Users\Steve\Documents\GitHub\JMRI\build.xml:440: java.nio.file.InvalidPathException: Trailing char < > at index 41: C:\Users\Steve\Documents\GitHub\JMRI\temp
In build.xml, line 440 is

<delete dir="${tempdir}"/>
ant panelpro works fine, the full ant error for the clean is

clean:
[delete] Deleting directory C:\Users\Steve\Documents\GitHub\JMRI\target
[delete] Deleting directory C:\Users\Steve\Documents\GitHub\JMRI\java\tmp

BUILD FAILED
C:\Users\Steve\Documents\GitHub\JMRI\build.xml:440: java.nio.file.InvalidPathException: Trailing char < > at index 41: C:\Users\Steve\Documents\GitHub\JMRI\temp
at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
--
Bob Jacobsen
@BobJacobsen


Win7 Unable to run ant clean / ant realcean

steve young
 

3 weeks ago I had no issues with running command line ant clean or ant realclean, Win 7 64 bit

Since these were last working, I have
Installed Win updates
Updated local JMRI via Github Desktop to latest head of master
Installed NetBeans 11.1

NetBeans clean also produces the exact same error.

Thanks in advance,

Steve.

BUILD FAILED
C:\Users\Steve\Documents\GitHub\JMRI\build.xml:440: java.nio.file.InvalidPathException: Trailing char < > at index 41: C:\Users\Steve\Documents\GitHub\JMRI\temp
In build.xml, line 440 is

<delete dir="${tempdir}"/>
ant panelpro works fine, the full ant error for the clean is

clean:
   [delete] Deleting directory C:\Users\Steve\Documents\GitHub\JMRI\target
   [delete] Deleting directory C:\Users\Steve\Documents\GitHub\JMRI\java\tmp
 
BUILD FAILED
C:\Users\Steve\Documents\GitHub\JMRI\build.xml:440: java.nio.file.InvalidPathException: Trailing char < > at index 41: C:\Users\Steve\Documents\GitHub\JMRI\temp
        at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)
        at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
        at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
        at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
        at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
        at java.io.File.toPath(File.java:2234)
        at org.apache.tools.ant.taskdefs.Delete.isDanglingSymlink(Delete.java:879)
        at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:642)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
        at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
        at org.apache.tools.ant.Task.perform(Task.java:350)
        at org.apache.tools.ant.Target.execute(Target.java:449)
        at org.apache.tools.ant.Target.performTasks(Target.java:470)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1361)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
        at org.apache.tools.ant.Main.runBuild(Main.java:834)
        at org.apache.tools.ant.Main.startAnt(Main.java:223)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)


Re: Netbeans Help

steve young
 

Thanks for all of the suggestions folks.

Installing GIT made little difference.
Although I was unable to do ant ant clean ( I'll start another topic re that ), I discovered during a build that the machine simply did not have enough oomph . . .

Have just managed to do a temp fix on dev. laptop and have installed NB :-)

Steve


Re: Jenkins build "unrecoverable error encountered application will terminate"

Peter Ulvestad
 

Working now in 4.17.5ish+jenkins+20191020T1755Z+R35f9872
--
Peter Ulvestad

JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org )
Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ )
Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ )
Edmonton Model Railroad Association - http://www.emra.club/


Re: Preview: alignment in gridbag layout

Dave Heap
 

Svata,

I've managed to make some time to have a quick test of your branches, looking only at the ESU series decoders, and found two very obvious problems:
1) The special ESU Function Map is missing.
2) The special (replacement) Speed Table pane is not rendering correctly.

As a personal opinion, on an onscreen side-by-side comparison of current master and your decoderpro_gridbag_spaces branch, I'm afraid I find the readability of the majority of your panes much lower.

Dave

On 17 Oct 2019, at 8:06 AM, Svata Dedic <svatopluk.dedic@...> wrote:

The 'just refactoring' branch:

https://github.com/svatoun/JMRI/tree/feature/decoderpro_layout_split

As written previously, this should just cleanup the code. Bugs in Dave's ESU Loksound fixed.

Alignment as seen on screenshots.
https://github.com/svatoun/JMRI/tree/feature/decoderpro_gridbag_spaces

Some minor changes to decoder files (more or less experiments):
- shorter wording
- hide Zimo func alt mapping when CV value does not enable it
- more even distribution of checkboxes in analog controls

They're rather minor, but it's the excess and repeated wording which makes the UI so bloated.


Re: classloader error

Randall Wood <rhwood@...>
 

This is fixed in https://github.com/JMRI/JMRI/pull/7526

The problem is that in 2.7.1 Jython stopped shipping a library that apparently caused class loading conflicts in Java 9, but apparently we relied on earlier versions of Jython to provide for us.

On Oct 18, 2019, at 11:44 PM, Dave Heap <dgheap@...> wrote:

Tried bisect again on a different Mac with different start points,

On 18 Oct 2019, at 9:32 PM, Dave Heap via Groups.Io <dgheap@...> wrote:

I'm getting a similar error with 'ant decoderpro' on my Mac on my local master up to date with origin master on a clean working tree. Tried Java 1.8.0_211, 1.8.0_221 and 1.8.0_231.

Git Bisect tells me:
27c1a9bed49c5ef8f9fa50a229c41bca7b5d3dd7 is the first bad commit
commit 27c1a9bed49c5ef8f9fa50a229c41bca7b5d3dd7
Author: Randall Wood <randall.h.wood@...>
Date:   Sat Sep 21 10:40:25 2019 -0400

  revert fa110c8a39

  fa110c8a39 demonstrated that there is a problem running Jython 2.7.1 on Windows with JMRI as is. The next step is to figure out what changed between 2.7.0 and 2.7.1 that this only fails on Windows.

:100644 100644 2c49b05d9e8debf6c0bf2f2f5e7347ff3ebfdcf5 25fa05285d2f22b117a0c8178de408769b003509 M    build.xml
:040000 040000 30822ca7c3d90e6ab354d594ec99659bb54f0e27 2cd42e51a12044bf017c66d69706e8f258ac914f M    lib

  DecoderPro version 4.17.5ish+heap+20191019T0319Z+R27c1a9bed4 starts under Java 1.8.0_221 on Mac OS X x86_64 v10.12.6 at Sat Oct 19 14:19:13 AEDT 2019 [main]

27c1a9bed49c5ef8f9fa50a229c41bca7b5d3dd7 is the first bad commit
commit 27c1a9bed49c5ef8f9fa50a229c41bca7b5d3dd7
Author: Randall Wood <randall.h.wood@...>
Date:   Sat Sep 21 10:40:25 2019 -0400

   revert fa110c8a39

   fa110c8a39 demonstrated that there is a problem running Jython 2.7.1 on Windows with JMRI as is. The next step is to figure out what changed between 2.7.0 and 2.7.1 that this only fails on Windows.

build.xml                       |   2 +-
lib/jython-standalone-2.7.0.jar | Bin 37021723 -> 0 bytes
2 files changed, 1 insertion(+), 1 deletion(-)
delete mode 100644 lib/jython-standalone-2.7.0.jar

Same commit, rendered slightly differently.

Do you still want me to try this:
On 18 Oct 2019, at 11:00 PM, Randall Wood via Groups.Io <rhwood@...> wrote:

If `git bisect` is getting you to a commit where Jython 2.7.0 is replaced with Jython 2.7.1, please try replacing Jython 2.7.1 with 2.7.0 and see if that works (running from HEAD of master). If that does work, it suggests that Jython 2.7.0 included some code that we relied on that wasn’t expected.

If so, I assume that means:
- Edit build.xml.
- Delete the Jython 2.7.1 jar.
- Reinstate the Jython 2.7.0 jar (what is best way to do this with correct permissions etc.)?

Dave


Re: classloader error

Dave Heap
 

Tried bisect again on a different Mac with different start points,

On 18 Oct 2019, at 9:32 PM, Dave Heap via Groups.Io <dgheap@...> wrote:

I'm getting a similar error with 'ant decoderpro' on my Mac on my local master up to date with origin master on a clean working tree. Tried Java 1.8.0_211, 1.8.0_221 and 1.8.0_231.

Git Bisect tells me:
27c1a9bed49c5ef8f9fa50a229c41bca7b5d3dd7 is the first bad commit
commit 27c1a9bed49c5ef8f9fa50a229c41bca7b5d3dd7
Author: Randall Wood <randall.h.wood@...>
Date:   Sat Sep 21 10:40:25 2019 -0400

  revert fa110c8a39

  fa110c8a39 demonstrated that there is a problem running Jython 2.7.1 on Windows with JMRI as is. The next step is to figure out what changed between 2.7.0 and 2.7.1 that this only fails on Windows.

:100644 100644 2c49b05d9e8debf6c0bf2f2f5e7347ff3ebfdcf5 25fa05285d2f22b117a0c8178de408769b003509 M    build.xml
:040000 040000 30822ca7c3d90e6ab354d594ec99659bb54f0e27 2cd42e51a12044bf017c66d69706e8f258ac914f M    lib

  DecoderPro version 4.17.5ish+heap+20191019T0319Z+R27c1a9bed4 starts under Java 1.8.0_221 on Mac OS X x86_64 v10.12.6 at Sat Oct 19 14:19:13 AEDT 2019 [main]

27c1a9bed49c5ef8f9fa50a229c41bca7b5d3dd7 is the first bad commit
commit 27c1a9bed49c5ef8f9fa50a229c41bca7b5d3dd7
Author: Randall Wood <randall.h.wood@...>
Date:   Sat Sep 21 10:40:25 2019 -0400

   revert fa110c8a39

   fa110c8a39 demonstrated that there is a problem running Jython 2.7.1 on Windows with JMRI as is. The next step is to figure out what changed between 2.7.0 and 2.7.1 that this only fails on Windows.

build.xml                       |   2 +-
lib/jython-standalone-2.7.0.jar | Bin 37021723 -> 0 bytes
2 files changed, 1 insertion(+), 1 deletion(-)
delete mode 100644 lib/jython-standalone-2.7.0.jar

Same commit, rendered slightly differently.

Do you still want me to try this:
On 18 Oct 2019, at 11:00 PM, Randall Wood via Groups.Io <rhwood@...> wrote:

If `git bisect` is getting you to a commit where Jython 2.7.0 is replaced with Jython 2.7.1, please try replacing Jython 2.7.1 with 2.7.0 and see if that works (running from HEAD of master). If that does work, it suggests that Jython 2.7.0 included some code that we relied on that wasn’t expected.

If so, I assume that means:
- Edit build.xml.
- Delete the Jython 2.7.1 jar.
- Reinstate the Jython 2.7.0 jar (what is best way to do this with correct permissions etc.)?

Dave


Jenkins build "unrecoverable error encountered application will terminate"

Peter Ulvestad
 

2019-10-18 20:31:41,182 util.Log4JUtil INFO - ****** JMRI log ******* [main]
2019-10-18 20:31:41,198 util.Log4JUtil INFO - This log is appended to file: C:\Users\Peter\JMRI\log\messages.log [main]
2019-10-18 20:31:41,214 util.Log4JUtil INFO - This log is stored in file: C:\Users\Peter\JMRI\log\session.log [main]
2019-10-18 20:31:41,245 apps.Apps INFO - PanelPro version 4.17.5ish+jenkins+20191017T2004Z+R293f0e1 starts under Java 1.8.0_221 on Windows 10 amd64 v10.0 at Fri Oct 18 20:31:41 MDT 2019 [main]
2019-10-18 20:31:41,870 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [main]
java.lang.NoClassDefFoundError: org/w3c/dom/ElementTraversal
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown Source)
at org.apache.xerces.dom.DeferredDocumentImpl.synchronizeChildren(Unknown Source)
at org.apache.xerces.dom.CoreDocumentImpl.getDocumentElement(Unknown Source)
at sun.util.xml.PlatformXmlPropertiesProvider.load(Unknown Source)
at java.util.Properties$XmlSupport.load(Unknown Source)
at java.util.Properties.loadFromXML(Unknown Source)
at jmri.profile.ProfileManager.readActiveProfile(ProfileManager.java:293)
at jmri.profile.ProfileManager.getStartingProfile(ProfileManager.java:906)
at jmri.profile.ProfileManagerDialog.getStartingProfile(ProfileManagerDialog.java:318)
at apps.Apps.<init>(Apps.java:185)
at apps.PanelPro.PanelPro.<init>(PanelPro.java:40)
at apps.PanelPro.PanelPro.main(PanelPro.java:120)
Caused by: java.lang.ClassNotFoundException: org.w3c.dom.ElementTraversal
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 36 more

--
Peter Ulvestad

JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org )
Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ )
Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ )
Edmonton Model Railroad Association - http://www.emra.club/


Re: classloader error

Steve_G
 

Hi Bob
I am using Linux 5.3.6-200.fc30.x86_64,
java-1.8.0-openjdk-1.8.0.222.b10-0.fc30.x86_64 /
java-11-openjdk-11.0.4.11-0.fc30.x86_64
Steve G

---------- Original Message ----------java-1.8.0-openjdk.x86_64
From: Bob Jacobsen <@BobJacobsen>
Date: October 18, 2019 at 12:24 PM


Here’s what I think we know so far:

Dave Heap reports it not working on his Mac v10.10.5 build and run with
1.8.0_211, 1.8.0_221 and 1.8.0_231

My Mac v10.14.6 build and run with 1.8.0_151 fails; build and run with 11+28
succeeds; build with 11+28 run with 8u151 fails.

Randall's Mac 10.15 fine with JDK 11.0.4, fails with JDK 1.8.0_222

Steve G (WIndows?) compile on 1.8(u number unknown), run under 11 no error;
compile and run on 1.8 fails

Klaus on Windows 7 fails with 1.8.0_151 (succeeds when Jython 2.7.0
reinstalled)

Bob
--
Bob Jacobsen
@BobJacobsen






Re: classloader error

Klaus Killinger
 

Jython 2.7.1 now works for me under Windows 7 and jdk1.8.0_144.
I followed the hints of Svata and Daniel, picked xml-apis-1.4.01.jar and added the path in build.xml under runtime.class.path.

Klaus


Re: JDK version issue in NetBeans

Svata Dedic
 

Dne 16. 10. 19 v 20:58 Andrew Crosland napsal(a):
"warning: Supported source version 'RELEASE_7' from annotation processor 'org.netbeans.modules.openide.util.ServiceProviderProcessor' less than -source '1.8'"
Did the world a little better: https://github.com/apache/netbeans/pull/1578

JMRI needs to wait for release 11.3 it's not critical to push it to upcoming 11.2.

-Svata


Re: classloader error

Svata Dedic
 

Finally not in the office, so I can work on free projects ...

Apologies for the contextClassLoader() misleading hint; I don't know Xerces 2.11 peculiarities since we still use ancient 2.8.0 in NetBeans and for newer projects basic JAXP in JDK was sufficient ...

It seems that JMRI is missing xml-apis library JAR. Xerces started to implement ElementTraversal (https://www.w3.org/TR/ElementTraversal/) in its version 2.11.
Those classes were for some reason shipped with Jython 2.7.0; when it was replaced for Jython 2.7.1, which still contains some version of Xerces, but seems repackaged to org.python.*

When I added xml-apis.jar to JMRI's runtime classpath, it started on JDK8.

ElementTraversal API is part of JDK 9 and later, that's why it works on JDK11.

-Svata

Dne 18. 10. 19 v 17:03 Randall Wood via Groups.Io napsal(a):

I think I need to go through the set of Java 1.8 versions to see if some change in some release of Java 1.8 caused this. It appears (from reading release notes) that Java 1.8 > update 201 selects the XML parser differently than older updates than that.
I also thought the call in question was covered by a test, but I see it isn’t (because the load apps tests specify the profile to use) so that test needs to be added as well.
Randall
On Oct 18, 2019, at 09:47, Bob Jacobsen <@BobJacobsen> wrote:

That’s interesting.

Jenkins is running “compile on 11, run alltest on 8” successfully.

Would it make sense to try building a test release with Java 11 as an experiment?

Bob

On Oct 18, 2019, at 6:31 AM, Steve_G <RailRodder@...> wrote:

Randall, Pete
If I compile and run with 1.8 I get the error. Compile with 1.8, run under 11 no error.
Steve G..
--
Bob Jacobsen
@BobJacobsen






Re: classloader error

Bob Jacobsen
 

Here’s what I think we know so far:

Dave Heap reports it not working on his Mac v10.10.5 build and run with 1.8.0_211, 1.8.0_221 and 1.8.0_231

My Mac v10.14.6 build and run with 1.8.0_151 fails; build and run with 11+28 succeeds; build with 11+28 run with 8u151 fails.

Randall's Mac 10.15 fine with JDK 11.0.4, fails with JDK 1.8.0_222

Steve G (WIndows?) compile on 1.8(u number unknown), run under 11 no error; compile and run on 1.8 fails

Klaus on Windows 7 fails with 1.8.0_151 (succeeds when Jython 2.7.0 reinstalled)

Bob
--
Bob Jacobsen
@BobJacobsen


Re: classloader error

Randall Wood <rhwood@...>
 

I think I need to go through the set of Java 1.8 versions to see if some change in some release of Java 1.8 caused this. It appears (from reading release notes) that Java 1.8 > update 201 selects the XML parser differently than older updates than that.

I also thought the call in question was covered by a test, but I see it isn’t (because the load apps tests specify the profile to use) so that test needs to be added as well.

Randall

On Oct 18, 2019, at 09:47, Bob Jacobsen <@BobJacobsen> wrote:

That’s interesting.

Jenkins is running “compile on 11, run alltest on 8” successfully.

Would it make sense to try building a test release with Java 11 as an experiment?

Bob

On Oct 18, 2019, at 6:31 AM, Steve_G <RailRodder@...> wrote:

Randall, Pete
If I compile and run with 1.8 I get the error. Compile with 1.8, run under 11 no error.
Steve G..
--
Bob Jacobsen
@BobJacobsen






Re: classloader error

Bob Jacobsen
 

That’s interesting.

Jenkins is running “compile on 11, run alltest on 8” successfully.

Would it make sense to try building a test release with Java 11 as an experiment?

Bob

On Oct 18, 2019, at 6:31 AM, Steve_G <RailRodder@...> wrote:

Randall, Pete
If I compile and run with 1.8 I get the error. Compile with 1.8, run under 11 no error.
Steve G..
--
Bob Jacobsen
@BobJacobsen