Compiled application only runs on the compiling machine

I have a strange situation where an application compiled on machine #1 only runs on #1 and not on #2. If I compile on #2, it then runs on #2 but not on #1.

The error I get seems similar to an issue that was fixed in R2014 - Arguments to IMPORT must either end with ".*" or else specify a fully qualified class name: "com.mongodb.MongoClient" fails this test. I've tried using the .*, I've tried not using import and using the fully qualified name instead, all of these run on the compiling machine but not on any other.

Has anybody encountered this problem as well? Any suggestions?

--------------------------------------------------------------

I've copied the PackagingLog.html file below:

mcc -o DAP -W WinMain:DAP -T link:exe -d C:\Users\oerc0003\Dropbox\Projects\DIET\DAP\DAP\DAP\for_testing -v C:\Users\oerc0003\Dropbox\Projects\DIET\DAP\DAP\dap.m -a 'C:\Users\oerc0003\Documents\MATLAB\Add-Ons\Toolboxes\GUI Layout Toolbox\code\layout\+uix\Resources' -r 'C:\Program Files\MATLAB\R2017b\toolbox\compiler\Resources\default_icon.ico' 
Compiler version: 6.5 (R2017b)

Dependency analysis by REQUIREMENTS.

[Warning: Package directories not allowed in MATLAB path:
C:\Users\oerc0003\Documents\MATLAB\Add-Ons\Toolboxes\GUI Layout
Toolbox\code\layout\+uix\Resources] 
Parsing file "C:\Users\oerc0003\Dropbox\Projects\DIET\DAP\DAP\dap.m"
  (Referenced from: "Compiler Command Line").
Deleting 0 temporary MEX authorization files.
Generating file "C:\Users\oerc0003\Dropbox\Projects\DIET\DAP\DAP\DAP\for_testing\readme.txt".
Packaging...
Creating the bundle...
Self contained installer created at C:\Users\oerc0003\Dropbox\Projects\DIET\DAP\DAP\DAP\for_redistribution\MyAppInstaller_mcr.exe.
Packaging complete.
Elapsed packaging time was: 50 seconds.

[Kojiro Saito]

Could you tell us the error message you encountered?

My guess is,

Machine #1 and #2 are the same OS?

or

Is there any difference of MATLAB path of Machine #1 and #2?

[Neil Caithness]

This is all on Windows 10 machines. I've tried to come up with some minimal code that replicates the problem.

I've added the following entries to my javaclasspath.txt file:

C:\ ... \bson-3.4.2.jar                                        
C:\ ... \mongodb-driver-3.4.2.jar                              
C:\ ... \mongodb-driver-core-3.4.2.jar

These are available here: MongoDB

Here's a short function:

function test()
import com.mongodb.MongoClient
ver
end

which I've compiled with

mcc -m test

Now executing on the compiling machine I get this:

>> !test
----------------------------------------------------------------------------------------------------- 
MATLAB Version: 9.x
MATLAB License Number: unknown 
Operating System: Microsoft Windows 10 Pro Version 10.0 (Build 15063) 
Java Version: Java 1.8.0_121-b13 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode 
[...]

Executing on another almost identical machine I get this:

>> !test
Error: File: C:\Users\oerc0003\AppData\Local\Temp\oerc0003\mcrCache9.3\test_50\test\test.m Line: 2 Column: 8 
Arguments to IMPORT must either end with ".*" or else specify a fully qualified class name: "com.mongodb.MongoClient" fails this test. 
MATLAB:mir_illegal_import_argument 
Error:Error: File: C:\Users\oerc0003\AppData\Local\Temp\oerc0003\mcrCache9.3\test_50\test\test.m Line: 2 Column: 8 
Arguments to IMPORT must either end with ".*" or else specify a fully qualified class name: "com.mongodb.MongoClient" fails this test.

This is reciprocal, I can compile on the second machine and it won't run on the first.

I've tried my full software package on a machine with no Matlab installed, but with the appropriate MCR, same result.

I've tried on yet another machine with R2017a and miraculously that works, but I can't seem to recreate that success anywhere else.

Any help much appreciated.

[Josh]

does any of this regexp trickery translate to practical application?

i understanding the importance of hacking but that's not really the point for applying regexp (you're not trying to improve your hacking skills via the Cody platform)

So I must go back to your first point about being the #1 ranked player, why is being ranked #1 on Cody so important to you?

in my mind, the most "efficient" solution is meant to offer those who wrote alternative algorithms an opportunity to learn something new, so that's why there's a desire to float the solution with the minimum size

as for having the highest Cody score, that doesn't necessarily require having the smallest solution for each problem. having the smallest solution earns a badge but not extra points every time (I may be wrong?), so the goal of having the highest Cody score actually has nothing to do with also earning the smallest solution for each puzzle.

conclusion - if you want to game Cody to earn points for a leaderboard that translates to nothing, have at it. it's your freedom of expression. but doesn't it seem a little selfish to also want your name at the top of every problem and prevent learning opportunities for others?

that's why people gripe about regexp, it's not because they care about leaderboards, it's because they want to learn and the regexp tricker doesn't offer any learning for algorithm writing. it's just a cheat to see your name on the internet more.

Answer 1

[Kojiro Saito]

It's due to Java class path difference of MATLAB and deployed environment. You need to add Java class path in deployed application. Please see this link.

Edited: I've reproduced the same error using MATLAB / MATLAB Runtime R2017a, the same jar files (bson-3.4.2.jar, mongodb-driver-3.4.2.jar, mongodb-driver-core-3.4.2.jar) on Windows 10 machines. Machine #1 is MATLAB, machine #2 is MATLAB Runtime only. I solved by adding jar files on machine #2 and adding classpath.txt under MCRROOT\toolbox\local where MCRROOT is MATLAB Runtime installation folder. To use jar libraries on deployed MATLAB Runtime environment, you need to (1) add the jar files to m files when compiling, or (2) copy the jar files on the deployed machine and add jar file paths on classpath.txt.

Ref: Editing classpath for Compiled program

I hope this works.

[Neil Caithness]

Thanks. Yes, I've been able to get this to work. I add the jar file in the deploytool, or use the mcc -a switch, both work. I think the error message could have been more helpful.

[Walter Roberson]

Nice investigation, Kojiro.

[Kojiro Saito]

Thank you for your feedback it's my pleasure.

Thanks, Walter.

[Neil Caithness]

Kojiro, I just want to properly say thank you. Compiler and packaging issues on multiple machines take a long time to investigate, so thanks for going to all that effort.