Please keep in mind that I know nothing about Matlab.
Matlab Builder JA lets developer build Matlab applications and export them into Java jars. That's great, I just have to produce a jar and I can then use it from other java code.
Does anyone know how much the single jar packaging module cost?
Is there any free version or similar freeware product?
Is there any other way to achieve the same thing -Using Java to pass inputs to Matlab and getting an output back without worrying about anything else- with standard Matlab/Java?
The Matlab JA Builder (also referred to as the Matlab JA Compiler) runs about $5k, but for the deployment to actually work you also need to get the MCR Toolbox, which is about $4k. This is of course on top of an existing Matlab installation which will run you about $2k. So for about $11k you can have a fully armed and operation workstation that converts .M file functions to a compressed .jar file that can be used in an arbitrary Java application. The cool thing is that these license fees give you a site license for DEPLOYMENT... meaning it is free to deploy any .jar file produced by this setup at the site that pays for the licenses to any target machine. The target machines do NOT need matlab installed. OS support exists for Win/Mac/Linux/Solaris last I checked.
However be advised that the license structure is for one site and for one development machine. You want two developers working simultaneously? double the costs. You want to deploy the same app to multiple sites... double the costs. call Mathworks they're very happy to tell you precisely what you need and don't need and you'll probably talk to an engineer and not some call center drone. I did all this at a previous job in 2009.
MATLAB Builder JA for Java is currently £3,150 for an individual commercial license, and requires MATLAB Compiler, which is currently £3,850 for an individual commercial license. I'm in the UK so can't get pricing in other currencies, but you can get your local prices from the following links.
Pricing for MATLAB Builder JA
Pricing for MATLAB Compiler
Contrary to Birdasaur's answer, the products (and the deployed components) are not supported on Solaris - MATLAB itself has not been supported on Solaris since R2010a. You can also deploy the generated .jar files to as many sites as you like. Individual licenses can be either assigned to a named individual, in which case only that developer can use the product; or to a specific machine, in which case any developer can use it as long as they are at the console of the machine (not remotely logged in).
MATLAB also has an undocumented interface called JMI (Java MATLAB interface) that you can use to call MATLAB directly from Java. Take a look at matlabcontrol. However, this requires a live copy of MATLAB for the deployed application.
You should probably contact MathWorks about licensing. As this is fairly high end functionality I would speculate that it is quite expensive.
You should probably take a look at Octave which is licensed under GNU GPL. Also, there are also a wide variety of wrappers around Matlab, such as MLabWrap, however they require a Matlab version installed, so it would not work for redistribution or anything.
Related
I found some reference that says I can add #!/usr/bin/java --source 12 at the beginning of the file and run the file directly from the terminal.
I am able to run using this on my local machine, however, when I tried the same on Github action I'm getting the error error: invalid value for --source option: 12
I'm not really an expert in shell scripting or java, can someone help me understand what this --source means is it the java version, I tried setting up the same version (jdk18) on Github action but still did not work.
java (the runtime executable) can only run class files. Until, that is, java12, where a normal JDK distribution (and not the bizarro JREs that some packagers like Azul publish ^1) has a java.exe that can run java files straight up. It's simple sugar - the compiler is still involved, of course. It's just that java will execute it for you.
You don't need --source 12; just java MySourceFile.java is fine. Edit that comment at the top of your source file, it should just be #!/usr/bin/java. The thing you do need is that java on your command line PATH is a java v12 or higher, and it is not. There isn't anything your java source file can do about this, you're going to have to impose on your users to have at least java12 installed or this simply does not and can not be made to work. It looks like you're on some linux distro or other; apt or yum or snap or whatever package manager you have will tell you how to fix this: Install java17, and uninstall the rest or use java-alternatives or whatever mechanism your package manager has to set the default executable (the one /usr/bin/java links to). Read the documentation of the package supplying java17, possibly following some links to the generalized java infrastructure package, it should tell you.
Mostly this is a red herring, this just isn't how java files are distributed. It's virtually pointless because:
Java is not a language that tends to be used for quick shell script-esque things. Such things tend to be self-fulfilling prophecies: Because nobody does this, library authors aren't thinking about it when they develop their APIs and the users of their libraries won't file enhancement requests for this either. Because common libraries aren't convenient when used for quick off-the-cuff shell scripts, java isn't used for it, thus perpetuating the cycle.
Any serious java app would definitely involve packages, dependencies, and more - and such apps cannot be run like this.
Class files are as platform agnostic as source files are. There is no sane reason to distribute java-written shell-script-esque tooling as a source file instead of a jar, except for off-the-cuff editing off them, which gets you right back to point #1 and #4.
The java core APIs work on a model of lowest common denominator: If there is a major OS that cannot or doesn't work in a certain way, then java simply does not expose this at all. For example, on all posix systems (i.e. pretty much every major OS except windows), you have your usual TERM, KILL, HUP, etc signals. Java core libs don't let you interact with them (unless you dip into hidden sun.misc.* API which doesn't reliably work in the first place). This makes java extra unsuitable for quick command line scripting where you want a different model: If at least one OS can do it, the language should have a library for it, and that library should simply fast-crash if you attempt to use it on an OS that doesn't support it. One easy way around this is a third party library that adds support for OS-specific stuff, but your model of distribution (stick #!/usr/bin/java at the top and distribute a source file) cannot include dependencies.
Java as a runtime model is mostly focused on running things eventually very quickly, at the cost of starting off slowly. This is fantastic for web servers which need to run efficiently but will be running for quite some time. It's utterly unsuitable for shell scripting, though.
CONCLUSION: You don't want to stick #!/usr/bin/java at the top even if you could make it work.
[1] A JRE is a java distribution without compilers and other development tools like jstack. These cannot run java SomeSourceFile.java, obviously; they do not have a compiler. However, JREs died - there are no JREs anymore; JDK8 is the last one that shipped with an official JRE. The JRE serves as a distribution model: The end user installs a JRE, and you ship your jars to them. This model is obsolete (you are now responsible to get something that can run your class files on the deployment machine), and therefore JREs died. However, some packagers of OpenJDK builds, such as Azul, still publish them, confusing matters. Hence, 'bizarro'. Azul and co have relatively good reasons for doing it, but, you shouldn't be using these unless you really know what you are doing.
I am attempting to port an application that was written with a combination of c++ for the back end, and java for the front end. This application relies on the library opencv 2.4.13, which is outdated, as well as multiple other libraries. The concern i have is that i do not want the end user to need to install these dependant programs, as they have been proving challenging to install on any but a select few linux distributions. I believe the term i am looking for is statically linking, but i'm a bit unfamiliar with c++ compilation at the moment, so i am unsure the steps i need to take to make these files portable. The java application requires these files to be libraries, and while i have managed to get them to compile on one machine, the problem seems to be getting them to run on a different one after compilation.
Don't bother - this might also give you licensing problems, depending on what libraries you need.
Instead, just figure out what platforms your application is supposed to run on and package the libraries for each platform with your jar - or download them at startup, or provide them as a separate package. The exact mechanics you choose depend on your use case, the point is you don't need to rely on system wide installs.
What I'd like to ask is if anybody knows about an hardware USB-dongle for software protection which offers a very complete out-of-the-box API support for cross-platform Java deployments.
Its SDK should provide a jar (only one, not one different library per OS & bitness) ready to be added to one's project as a library.
The jar should contain all the native stuff for the various OSes and bitnesses
From the application's point of view, one should continue to write (api calls) once and run everywhere, without having to care where the end-user will run the software
The provided jar should itself deal with loading the appropriate native library
Does such a thing exist?
With what I've tried so far, you have different APIs and compiled libraries for win32, linux32, win64, linux64, etc (or you even have to compile stuff yourself on the target machine), but hey, we're doing Java here, we don't know (and don't care) where the program will run!
And we can't expect the end-user to be a software engineer, tweak (and break!) its linux server, link libraries, mess with gcc, litter the filesystem, etc...
In general, Java support (in a transparent cross-platform fashion) is quite bad with the dongle SDKs I've evaluated so far (e.g. KeyLok and SecuTech's UniKey).
I even purchased (no free evaluation kit available) SecureMetric SDKs&dongles (they should've been "soooo" straighforward to integrate -- according to marketing material :\ ) and they were the worst ever: SecureDongle X has no 64bit support and SecureDongle SD is not cross-platform at all.
So, has anyone out there been through this and found the ultimate Java security usb dongle for cross-platform deployments?
Note: software is low-volume, high-value; application is off-line (intranet with no internet access), so no online-activation alternatives and the like.
-- EDIT
Tried out HASP dongles (used to be called "Aladdin"), and added them to the no-no list: here, too, there is no out-of-the-box (out-of-the-jar) support: e.g. end-linux-user has to manually put the .so library (the specific file for the appropriate bitness) in the right place on his filesystem, and export an env. variable accordingly.
Full disclaimer: I work for a company that makes software-protection dongles (CodeMeter). But I believe we might have a solution that meets your requirement: we have a single API for all platforms (Win, Mac, Linux, etc both 32- and 64-bits). Each end-user machine merely requires a runtime (service on Windows; daemon on Linux). We use a native Java API which uses TCP/IP to call our runtime, so no special device drivers are required. You can do activations either before you ship the dongle (pre-programming), or via file exchange (NikeNet) on deployments with no Internet access, or you can remove the dongle, take it to a machine that DOES have Internet connectivity and update the license there.
At a higher level than the API we have AxProtector, which is an automated protection/encryption tool that you can use to test our protection system with no source code changes. This would let you test the implementation on all platforms you are interested in--you don't need to create multiple versions for different platforms.
We had a Fortune 100 company use this to protect a Java app that ran on non-Intel Solaris, so we know it's been stress-tested as a cross-platform solution.
We have a free fully-functional eval system which we can get you asap. If you email me at the email address in my profile we can ship you out an SDK and help you quickly determine if this will solve your problem.
You can use Dinkey Pro dongles to achieve exactly this. While they do use separate native libraries for each operating system and architecture you just need to call their Java API and it takes care of any platform specific bits. Wrap the libraries up in a JAR file with the .class (the API) and you've got a neat solution. The dongles themselves are driverless.
I can only recommend to avoid the SecuTech UniKey system. During evaluation the product met all requirements we needed. We started integrating this solution and discovered one issue after another.
Here is a short list of the major issues that are part of the SDK 6.2.7:
Enveloper settings change randomly when saving and loading the same solution (Video).
DLL files that are wrapped with the enveloper do not load.
The console version of the enveloper for script based builds does not work. It is unable to wrap exe/dll's that can be wrapped with the GUI based version of the enveloper.
Support is reactive but does not really tackle the problems.
After all we wasted almost a month of work integrating this protection system, but now have to switch due to the massive quality issues.
I'm wondering if there is a standard method for deploying applications originally written in Java, to iOS4 devices.
I assume that the application in original format cannot be deployed - is there perhaps an emulation layer that I can use, or a stable compiler that compiles Java to ObjectiveC?
Option 1:
Use one of several cross compilers, compiling Java to ObjectiveC:
http://www.xmlvm.org/overview/
http://www.flexycore.com/ispectrum-overview.html
Option 2:
Package custom JVM with java application, with restrictions that meet the latest agreement (including no byte-code download capability and no JIT compilation). No JVM specifically designed for the iPhone is currently (Oct 2010) available, though the IKVM might run on top of Monotouch, and Oracle may build a version of the Java SE for the iPhone eventually.
Option 3:
Cross compile Java to one of the existing interpreters that are already accepted on the iPhone (eg, cross compile Java to C# and run the app on monotouch)
With the new current iOS SDK agreement and App store rules, it may be possible for you to embed a Java applet with your own JVM interpreter and runtime engine (but no byte-code download capability and no JIT compilation allowed).
Another seldom mentioned possibility for deploying any non media or graphic intensive networked app, such as many typical Java applets, is to run a customized RDP or VNC viewer on the iPhone and and view a Java app that is being hosted and run remotely.
Mechanically translating some of your code will likely work pending finding a cross compiler / translator. Trying to run a Java based GUI on iPhone is just plain stupid in my opinion. So the smart thing would be to port the GUI by hand.
The problem of course is if the app is mostly GUI you might as well write the whole thing over. Likewise if the app uses APIs that there is not a simple translation for you again might as well rewrite the entire app.
In a nut shell I think Steve J. Was right here, the route you are comtemplating just leads to poor user experiences. It actually makes me wonder why you would even think that a Java based app would be successful on iPhone.
I would like to know if there is any way that I could build a very simple GUI app (it doesn't even have to look good) that will run on a fresh install of Windows Vista and OS X with no other installations needed by the user. I would perfer not to use Java (just out of personal programming preference). I will use it though, if it is the only way. Specically, I am wondering if I can write a swing app with Scala or Groovy and run in on windows without them having to install anything. Sorry if this is a silly question, I am a Obj-C developer by trade.
You can pack the Scala jars into your own, which should work as long as Java is installed (which it usually is on a 3rd party vendor install of Vista or OS X). If you use Java web start, no installations are needed beyond Java itself. Plus, if you're going to install your own code, why not just copy along the Scala jars also?
If you really mean a fresh install--nothing but what the OS provides--then no, I don't think so.
Edit: You do always have javascript on the browser(s). I assume this won't cut it for what you want?
If you really, really don't want to install anything (or carry anything in your app), then write the application as a web app (possibly a javascript app). Then any user can run that UI from any machine with a decent browser. But then, this will require that you host the app somewhere.
If that is not an option, you can develop your app to as a single html/xhtml file containing a self-contained, self-modifiable javascript application (like TiddlyWiki which I use a lot). Then the user user can download on it on his machine, point his browser to it and voila.
If you combine javascript with HTML5 (and assuming the user has a HTML5 compliant browser like safari), your application can use localStorage to keep its state in the user's machine (thus no longer needing to be self-modifiable to save state as TiddlyWiki does.)
But this would break your rule of not downloading anything on the user's host machine. It is a chicken-and-egg problem that has no solution since each OS implements its own set of application libraries. For multi-platform support, you must use a layer that abstracts out differences between operating systems, be it a vm (like JVM, Ruby or Mono) or a set of libraries (Qt, Gnome).
As far as i know you won't be able to accomplish that with no other installations needed by the user. If you violate this restriction, mono (with gtk#) is a good choice.
Scala and Groovy will have the same deployment issues as Java; all of these require a JVM to be installed. You generally have to first install the JVM (which is not included with Windows) and then install your program. Java is included in OS X, however.
It is possible to use Ruby or Python and one of the cross platform libraries (like wxWidgets) and compile these to an executable file that includes the entire set of runtime libraries (e.g. all of ruby and python).
REAL Studio (formally REALbasic) certainly meets this requirement. It creates native applications that have no external dependencies for OS X and Windows (plus Linux).
In theory you could write a .net application using Mono that it should run without issues on any other one with the .net runtime environment installed.
But I'm not sure if it will work on practice.
I've had some success with XulRunner
There's also a couple of recommendations from these questions I asked
Building Cross Platform app - recommendation
Building XUL app a-la SongBird
XULRunner is pretty cool once you get into it, but it's a tad confusing at first (I thought).. the folks on the mozilla google groups are really nice and helpful though!