Why does processing-java.exe print "Listening for transport dt_socket at address: xxxx"? - Processing Forum

Loading...

Processing Forum

Integration and Hardware

jamesbritt

Why does processing-java.exe print "Listening for transport dt_socket at address: xxxx"?

in Integration and Hardware • 1 month ago

I'm using version 2.0.3 32-bit on Windows 7 Pro 64-bit.

I typically execute sketches from the command-line using processing-java.exe. However, using 2.0.3, I set the following printed to the command window:

Listening for transport dt_socket at address: 8088

The port number will vary.

This is followed by an error:

java.lang.ClassNotFoundException: Files

at java.net.URLClassLoader$1.run(URLClassLoader.java:202)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

and that's as far as it gets.

Some Googling tells me this port access for attaching a debugger. I'm not deliberately looking to do that, so why is processing-java doing this?

I looked in preferences.txt but see nothing that suggests debugging is turned on or that any special arguments are to be passed to java other than memory settings.

The same sketch runs fine if loaded into the Processing IDE, but that's a clumsy way to run a sketch since I'm using an external editor.

EDIT:

I grabbed the code from Github to see if that would give better results. It does not. I poked around, added some debugging printlns, and it seems the trouble is that the code that generates the java comma nd line call is passing along a value for the java library path that includes my entire %PATH% contents. That includes paths that have 'Program Files" in their name, and I think the space in the file path is what breaks things.

What's odd is that I think this same code is used to invoke the Processing IDE, and I can use processing-java to generate an exported application. I just can't run my sketch that way.

1

Replies(4)

dimkir

dimkir

Re: Why does processing-java.exe print "Listening for transport dt_socket at address: xxxx"?

1 month ago

As to my understanding whenever you run sketch (at least in java mode), you will always have a module loaded to memory, which will be used for establishing communication channel between your running sketch and "debugger". (Debugging here is meant in "broad" sense, for example when in PDE you press "stop" button and it stops the sketch, that's PDE is sending message to the sketch, via this communication channel.).

It seems that even when processing runs the sketch via command line, it still includes this "debug stuff".

In your case it looks like you're missing some class. I guess it may be class from inside of

processing-2.0.2\lib\

folder. Maybe in version 2.0.3 contents of this folder isn't automatically included into classpath so you're missing some file.

Maybe in your case it's better to fall back to 2.0.2 or 2.0.1 to be sure that everything runs from command line ok.

I for example keep all releases of Processing, becase sometimes even newer and latest releases have broken functinoality. (For example releases later than 2.0b7, have P3D implementation which doesn't work on Intel Graphics adapters, which means that on ALL 3 (three!) of my laptops I can't run 3D sketches. So I have to still use 2.0b7 despite it is broken in few places).

ps. I am trying to follow the principle "If the release works for you and doesn't crash DON'T UPGDADE" (or at least wait for a few weeks to see the main complaints).

jamesbritt

Re: Why does processing-java.exe print "Listening for transport dt_socket at address: xxxx"?

1 month ago

I've got it working by adjusting my PATH values to avoid all blank spaces.

The problem is that processing-java.exe (for multiple versions, including what I pulled from GitHub) creates a large string that gets passed to to define java.library.path when invoking java.

This string turns out to be the value of %PATH% (why, I have no idea, since it's overkill).

On Windows, this string will almost certainly have spaces: any path item that is under "c:\Program Files" (for example) breaks the java invocation because the space ends the string passed to java.library.path and what comes next is interpreted as file to process

This is why the error reports not finding the file "Files"; it is the first text after a space.

So, it turns out that the the debugging port thing is not in itself breaking anything; it's just part of what remains just before processing-java fails to run. It would be nice to be able to turn this off, but the real issue is that processing-java.exe does not correctly handle white space in the path strings it creates.

PhiLho

PhiLho

Re: Why does processing-java.exe print "Listening for transport dt_socket at address: xxxx"?

1 month ago

Java always had some kind of issues with whitespace in paths. That's why I install all my Java applications in a C:\Java folder. Sometime it is not a problem, but better safe than sorry...

jamesbritt

Re: Re: Why does processing-java.exe print "Listening for transport dt_socket at address: xxxx"?

1 month ago

That's why I install all my Java applications in a C:\Java folder.

Sure, and I install Processing in a location with no spaces in the path.

That doesn't help if the a wrapper program is creating a path argument to pass to java.exe or javac.exe and that path argument does not have white-space correctly escaped.

Top Reply