THIS ISSUE WAS DUE TO STALE JARS/CLASSES BEING RETAINED IN
MY LOCAL JAVA WEB START CACHE ...
RESOLVED.
USING THE JAVA WEB START CACHE VIEWER
javaws -viewer
The application was deleted, (and deleted applications deleted)
Then reloaded fresh, and the correct jars were used.
This calls into question, for me, the reliability of Java Web Start for
deployment of my own apps...

Using API 2.7.7 standalone. Is IClientGUI.getClientChartController() in the 2.7.7 API ?

I'm puzzled since it compiles (Eclipse) but fails at runtime. That was the only line I added to an otherwise tested and stable compile. I checked carefully that the (signed) API 2.7.7 jar was on the classpath, in my jnlp deployment descriptor. Any ideas? One possibility was that I used jarsigner to sign the JForex-API-2.7.7.jar but all other methods seem fine . But that shouldn't be the problem. I was careful to make sure all dependent jars were appropriate for the 2.7.7 configuration.

            clientGUI = getClient().getClientGUI(chart);
            chartController = clientGUI.getClientChartController(); // Line 431 <-- no such method
            chartController.addMouseListener(this);

Exception in thread "AWT-EventQueue-0" java.lang.NoSuchMethodError: com.dukascopy.api.IClientGUI.getClientChartController()Lcom/dukascopy/api/IClientChartController;
   at com.fs.HyperScalperConsoleSA.postConnect(HyperScalperConsoleSA.java:431)
   at com.fs.HyperScalperConsoleSA.initialConnect(HyperScalperConsoleSA.java:532)
   at com.fs.HyperScalperConsoleSA.access$2(HyperScalperConsoleSA.java:471)
   at com.fs.HyperScalperConsoleSA$5.actionPerformed(HyperScalperConsoleSA.java:264)
   at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
   at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
   at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
   at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
   at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
   at java.awt.Component.processMouseEvent(Unknown Source)
   at javax.swing.JComponent.processMouseEvent(Unknown Source)
   at java.awt.Component.processEvent(Unknown Source)
   at java.awt.Container.processEvent(Unknown Source)
   at java.awt.Component.dispatchEventImpl(Unknown Source)
   at java.awt.Container.dispatchEventImpl(Unknown Source)
   at java.awt.Component.dispatchEvent(Unknown Source)
   at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
   at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
   at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
   at java.awt.Container.dispatchEventImpl(Unknown Source)
   at java.awt.Window.dispatchEventImpl(Unknown Source)
   at java.awt.Component.dispatchEvent(Unknown Source)
   at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
   at java.awt.EventQueue.access$400(Unknown Source)
   at java.awt.EventQueue$2.run(Unknown Source)
   at java.awt.EventQueue$2.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
   at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue$3.run(Unknown Source)
   at java.awt.EventQueue$3.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)

The screenshot shows Eclipse recognizes the method and, of course, it compiles.

I wonder if there's some problem with the JForex-API-2.7.7.jar ?

I fetched the jars with maven, as instructed.

As a sanity check, JForex-API-2.7.7.jar has size 535,135 (with "size on disk" 536,576) on a Windows 7 system.

I just wonder whether somehow the jar is incorrect.

Hey hyperscalper

This one here looks like a version inconsistency between eclipse's classpath and your runtime one.

Eclipse definitely sees 2.7.7 hence the auto-complete gives you IClientGUI.getClientChartController() in the dropdown.

I don't remember there being a 2.7.6 but in 2.7.5 IClientGUI.getClientChartController() doesn't exist.

Try placing the following in your onStart() to confirm which runtime your environment is bounded to during execution:

context.getConsole()..getOut().println(Instrument.class.getPackage().getImplementationVersion());

Your error says it wont return 2.7.7.

But maybe these aren't being updated in the Build process at Dukas ??

Interesting idea, so I did it for a couple of classes:

From main, for IClientGUI.class.getPackage().getImplementationVersion()

2.7.2

From onStart inside the IStrategy being run from the standalone API, as you suggested:

print("Version sanity check: "+Instrument.class.getPackage().getImplementationVersion());

also reports 2.7.2

I'm confused.

HyperScalper

BINGO !
OK, when I run it under Eclipse, I get the expected 2.7.7, in both cases, so I'll check some classpath or path items as the source of the problem.

THANKS A LOT FOR THE TIP !!

But here's the thing:

All of the jars are signed and deployed in my jnlp.

So Web Start should manage the classpath, right?

It's at runtime in the Web Start runtime context, where I get the exception.

As shown above, when run in Eclipse, the versioning looks good.

Anywayz..... thanks for the tips Any ideas? I could post the jnlp..... boring ...

HyperScalper

OK, nuked the application out of the Java Web Start cache, and deleted the deleted applications.

Reloaded the app off the webserver from jnlp and...

BINGO !! Perfect.

So Java Web Start was retaining stale classes. That's a pisser, ain't it ???

Thanks again for the tip on getting the runtime class versioning )

HyperScalper

So now I've got a working MouseListener on my API activated chart.

Really looking forward to the next API where we can control more aspects of the charts.

Obviously would like to get time and price from mouse click on the charts.

I know it's coming, eventually

HyperScalper

I was going to say exactly this, that running the standalone code from eclipse should work as expected as eclipse sees the correct runtime.

Running the standalone app at the command line uses the classpath of the OS environment or -classpath parameter.
so I guess the references to Java Webstart are related to running the strategy within the JForex platform.

Stale JavaWS cache updates can be forced in the jnlp as follows (if I remember right):

<update check="always" policy="always">

javaws -uninstall <jnlp-file> whenever there's a version change announced by Dukascopy is another way.

TIP:
In addition to the version number check above, the following can help identify which jars on the disk drive classes are coming from:

String _bind = ClassLoader.getSystemResource(Instrument.class.getName().replace(".","/").concat(".class")).getPath();
System.out.println("Bound to jar: " + _bind.substring(0, _bind.lastIndexOf("!")));

I use both techniques at the top of my client code as follows:

String _bind = ClassLoader.getSystemResource(Instrument.class.getName().replace(".","/").concat(".class")).getPath();
System.out.println("JForex Client Runtime v" + Instrument.class.getPackage().getImplementationVersion());
System.out.println("Bound to jar: " + _bind.substring(0, _bind.lastIndexOf("!")));

which yields:

JForex Client Runtime v2.7.5
Bound to jar: file:/run/media/devbase33/dev/forex/quantcode/lib/jforex/2_7_5/JForex-API-2.7.5.jar

edit: quick update to the tip above.

ClassLoader.getSystemResource() makes reference to the system class loader currently in control which under the likes of Maven exec plugin or other shells might not be the default system one which leads to a potential NullPointerException retrieving a resource.

The portable work around is to use a local anonymous class to retrieve a reference to the default system class loader that will load all application classes and of course have access to the application classpath:

try
{
   final class _bindlocal {};
   String _bind =  new _bindlocal().getClass().getClassLoader().getResource(Instrument.class.getName().replace(".","/").concat(".class")).getPath();
   System.out.println("JForex Client Runtime v" + Instrument.class.getPackage().getImplementationVersion());
   System.out.println("Bound to jar: " + _bind.substring(0, _bind.lastIndexOf("!")));
}
catch(NullPointerException npe) {}

String _bind = Name.class.getClassLoader().getResource(Instrument.class.getName().replace(".","/").concat(".class")).getPath(); works also where 'Name' is the name of the class containing the above functionality (different class / different corresponding name). The NPE try catch addresses 'exotic' JVM implementations or Classloader Shells that disrupt common class loading behaviour.