I am trying to use Emscripten's emconfigure and emmake to compile OpenJDK for the web. The end goal would be to be able to run uncompiled java code natively in the browser. However, running emconfigure ./configure throws the error
configure: The C compiler (located as /usr/lib/emscripten/emcc) does not seem to be the required gcc compiler.
configure: The result from running with --version was: ""
configure: error: A gcc compiler is required. Try setting --with-tools-dir.
I have been searching all day and I haven't found anything along the lines of this error. Is there any easy workaround for this? Should I even be trying to build OpenJDK this way?
Is there any easy workaround for this?
I doubt it. If you look at (for example) jdk11u/make/autoconf/toolchain.m4 you will see the toolchains that are supported on various platforms. Emscripten is not listed.
I expect that emconfigure is trying to use the JDK's autoconf-based configuration framework. And that framework is checking the compiler you are trying to use ... and saying Nope!
You may be able to modify the auto-conf macros to support the Emscripten tool chain. But the next problem will be getting the code to actually compile. And then to getting it to run.
Should I even be trying to build OpenJDK this way?
It is not up to us to say what you should do.
However, I would make some observations.
If you are expecting this to work without significant effort, you are sadly mistaken.
What you are doing is equivalent to trying to port Java to a new OP platform and hardware platform. This is is a massive project. In addition to just getting the JVM to compile, you also have the problem of getting the Hotspot JIT compiler to generate WebAssembly code.
This is probably a bad idea anyway. Once upon a time, mainstream web browser vendors did support Java in the browser. But there were so many "security issues" that (virtually) all vendors have dropped support. Oracle saw the writing on the wall, and in Java 9 they started the process of removing support from the OpenJDK codebase. Applet support and JNLP are gone, and they are planning to get rid of the SecurityManager framework.
What you would be doing is bring back Java support in the web browser ... with the security safeguards stripped out.
Basically, the Java SE platform is to rich to implement securely in a web browser.
If you are still keen on building a JVM using Emscripten, take a look at https://github.com/emscripten-core/emscripten/issues/3342.
But note that they are talking about building JamVM, which is Java 1.6, and hasn't been touched since 2014.
Related
I made a java program that I want to upload on a website. I want it to be available to download for everybody. I read many things about Oracle OpenJDK and OcacleJDK but I do not really know how this is connected to my program. And if I made my program with the Oracle JDK, how can I change it to work with the Oracle Open JDK?
Edit:
Sorry, I do not really know that much about JDK's and so on... That I understand this correct, the JDK is not bound to the program. The end user needs to have the JDK installed on the computer. Because I am not sure, if I need to buy a java license.
And if I made my program with the Oracle JDK, how can I change it to work with the Oracle Open JDK?
No need to change it.
Understand that the Java platform is defined by a set of specifications. Any implementation that complies with those specs can run any Java-based app. To ensure compatibility, an implementation may be subjected to test suites published by Oracle (TCK) or by Adoptium (AQA).
If you write a Java app using an implementation of Java 11, for example, then that app can run on any other implementation of Java 11. And most likely, that app will run an any implementation of future versions of Java.
Oracle JDK is a product from Oracle that implements the Java specifications. This product is commercial, requiring a fee for use in production, with support available. Oracle also releases an unsupported free-of-cost product that is an implementation of Java that oddly does not exactly have a name, found here.
Both of those products are built from the open-source project OpenJDK. Several other vendors also release implementations of Java based on this source code. You can build your app using any of these, and run your app using any of these.
Your use of the phrase “Oracle OpenJDK” is not accurate. While Oracle founded the project, and provided the bulk of the source code, the project is also backed by IBM, Apple, and others contributing important parts of the code base.
Here is a flowchart to help you in selecting a vendor. The products found inside the blue barrel are built entirely or nearly entirely from the source code provided by the OpenJDK project. The two products outside the barrel use parts of OpenJDK, but have significant portions built from other source code to provide their special features.
I want it to be available to download for everybody.
Your app needs an implementation of Java to run.
Your user can have an implementation of Java installed locally on their computer. Then you probably should build a JAR file containing your app for distribution.
You can include an implementation of Java bundled inside of your app. See the jlink tool. You can then make a complete self-contained "double-clickable" app that runs like any other app. Search Stack Overflow to learn more.
Because I am not sure, if I need to buy a java license.
Some of the Java implementations require a fee in some circumstances, and that also buys you support in all the cases I know of.
Some of the Java implementations are free-of-cost. Of course you do not get the benefits of paid support, unless you engage a support service company separately.
The key concept to remember is that the OpenJDK project provides only source-code but not binaries/installers. For binaries/installers, choose a vendor following the flowchart I posted above. For newbies wanting a free-of-cost implementation of Java, I suggest Adoptium (formerly known as AdoptOpenJDK), as this is a cooperative effort involving nearly all of the other vendors.
That I understand this correct, the JDK is not bound to the program.
True, your Java-based app is never bound to a JDK (Java implementation). After deployment, the Java implementation could be replaced by another while leaving your Java app untouched, no need to recompile. A JVM launches first, and then uses a Java class loader to load your app’s classes from your JAR file. A JVM is actually the app running on top of the host OS. On top of the JVM is your app running. So: host OS > JVM > your app classes.
This means your Java classes are not bound to the Java implementation, not in the sense of a linker in conventional software.
Caveat: What I discussed above is generally the case. GraalVM is very special in that it enables ahead-of-time compilation, for a different runtime situation. But that is cutting-edge technology, and not commonly used. Project Leyden is a possible similar effort.
I suggest reading the white paper Java Is Still Free.
As far as I know, I can run .mex files on Linux that were generated on Windows by installing Matlab Runtime on Linux (correct me if I am wrong). But what if I want to use a MATLAB generated java package, that was generated on Windows, on a Linux (like Ubuntu)?
Objective:
I have to test a feature that uses audio processing. If test is successful, we will buy the products we need. At the moment I have my requested license on Windows, since the requested license have machine specific limitation, I am able to generate some test java code on my Windows machine, now the application is to be deployed on android, so I learnt from google that it needs matlab runtime to run or compiler to use converted/generated code. Android system has no MCR or simple Matlab Runtime installation support, so I moved to this solution.
Use a linux to host servlet that takes some input from android, do processing return answer in terms of json or text. Now my java package is generated using Windows machine, and I am lost.
From my knowledge this code-convert-servlet-deploy-once approach is cost effective than MATLAB Production Server, since we have to buy license once for the specific products. Remember licensing phase is after we test if this approach is giving us desired results.
Specs:
Windows 10
MATLAB 2016a (Trial)
MATLAB products (Compiler/sdk, Signal Processing/Audio Processing Toolbox)
Package made using JDK 1.7.x (Exactly matching MATLAB jdk/jre version on Windows)
Ubuntu 16 Desktop (with Oracle jdk 8_101 installed, also MATLAB Runtime installed, I can also work with jdk 7.x (same as MATLAB used on Windows when generating package))
Questions:
How can I use this java package in Linux when I create a java program?
What software + licenses are needed to make it possible?
Should I install MATLAB ON Linux machine, generate Java Package ON Linux machine and use that package in java program ON same linux machine? ( I think I will need to request license for it again )
Are there any other methods? Am I missing something?
Java packages generated by MATLAB Compiler SDK are in general cross-platform - however, they may call mex files, or other libraries, that are platform-specific, and if they do the Java package as a whole will end up being platform-specific.
You aren't entirely clear about whether you're calling mex files or not; and you may be calling platform-specific libraries without realising it (for example, Signal Processing Toolbox might call out to some library for some of its operations).
In addition, your comment about being "able to run mex files on Linux that were generated on Windows by installing the MATLAB Runtime on Linux" is confused - mex files are not cross-platform, and the don't use MATLAB Runtime at all.
So with respect to platforms - you may be able to use a Java package generated on Windows on Linux, so long as it doesn't call any Windows-specific mex files or libraries. But if you generate it on Linux, you can rule that issue out, so it will be easier for you if you use the same platform for compilation and execution. It should be fairly easy for you to reassign your MATLAB license to a Linux machine to do that.
Am I missing something?
Yes: the way you're proposing to do things is very unlikely to scale well. If you have a Java servlet on your Linux server along with a Java package generated by MATLAB Compiler SDK, then whenever you make a call to the servlet it will make a call to the Java package, which will start up the MATLAB Compiler Runtime (MCR), run your MATLAB code, return the answer to the servlet, and then shut down the MCR.
The MCR takes quite a long time to start up (nearly as long as MATLAB). So each call will take rather a long time, just due to MCR startup times.
So you can get around that by creating some sort of utility tool that will start up a an MCR and keep it there, and pass through requests and return answers to the servlet.
But then you've only got one MCR - what happens if you get multiple requests at once? They'll be queued up (or dropped) and it won't scale. So you'll need to improve your utility tool, so that it manages a pool of MCRs and passes requests through to a free one, load-balancing them as it goes.
But then what happens if an MCR crashes, or runs ouot of memory? The utility tool will need to monitor that possibility, and restart any crashed ones.
And you'll need some extra stuff that will enable you to administer all that stuff conveniently.
Once you've done all that (which will be hard), you'll realise that you have now pretty much written MATLAB Production Server. I know it's expensive, but you might like to take another look at it before committing to the solution you're considering.
When I'm making a new JNLP file, I have to enter the versions of JAVA that my applet can work with, for example
<j2se version="1.6+">
Obviously, I want my applet to work with as many versions as it can, (I do, right?) how can I know what is the minimum required version to run my applet?
obviously, I want my applet to work with as many versions as it can, (I do, right?)
I disagree. It is well known that running Java in the web browser is a security nightmare. The best approach (for your users' security!) is to not use applets at all. But if you must do it, then you should be aiming to do it as securely as possible. That means writing your JNLP file to insist on a recent version of Java. Preferably, the most recent patch level of Java 7.
But to answer your Question, the simplest test to find the oldest a version of Java should support your application is to attempt to compile it with that version of the JDK. If it compiles on an old version JDK, then it is fairly likely that it will run.
But then you should test it, because successful compilation does not guarantee that the application will run properly.
And as #Lonzak points out, there is a separate issue of whether the user's installed Java supports JNLP.
There ought to be a better way but the following are the most general ones in my opinion:
Set the version of the Java Applet in your IDE to the lowest version you want to support and start programming.
Check the libraries/functions you need and check in which version they have been added.
When you want to use the JNLP mechanism you are bound to the next generation java plugin. It is supported starting with Java 1.6.0_10 (6u10). Java version older than that does not support JNLP. So if you want to support older Java versions you have to use the "old" mechanism (e.g. applet, object and embed tags).
So what would could you do?
Write a preceding applet, which is compiled with Java 1.4 (or even earlier). This applets basically only checks the Java version and other prerequisites. If the Java version is not sufficient (<6u10) it displays an error and otherwise the JNLP based applet is started...
I want to integrate java compiler in my application but I don't have any idea how will I do that.
I want that user could compile and run code on my application.
If anyone can help me then please tell me from where I should start.
Starting Java 1.6, the standard JDK ships with an API to the compiler. Meaning, you can easily write a Java program that will compile other programs.
http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html
EDIT as per Aaron's comment: an application using the compiler API must be run using the full JDK. The JRE doesn't include the compiler API implementation.
A second alternative is to embed the Eclipse Java compiler into your code. The advantage of this is that your application doesn't need a SDK to run - just add this single JAR.
Details are documented here: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_batch_compiler.htm
Note: Adding a compiler to an application creates an enormous security risk. It basically means anyone can start doing anything with your application. Things that spring to mind are:
Attacking other computers, people and sites
Looking at all the data on the computer on which the application is running
Analyzing the network the computer is in and attacking any other computer in the same network
Installing Trojans or viruses on the computer
We have a web application that uses a third party java applet for encryption and authentication. It's always been a bit finicky, but right now it has me pulling my hair out.
Over the weekend, we migrated to a MS Load balanced cluster, upgraded our DNS, and rolled out all of the MS patches. Now the applet fails for all of our users who are using the MSJVM. The solution is simple, we just have them install a recent version of Sun, but I cannot figure out why the MSJVM is failing.
Every other configuration works (Firefox, Safari, IE with Sun on Window, Linux or Mac) or I can get to work with a reasonable amount of effort, but nothing I can do will make MSJVM work.
I understand the MSJVM is depreciated, but nothing on the site (http://www.microsoft.com/mscorp/java/default.mspx) indicates that it should no longer work. I am looking for information that will either allow us to make the MSJVM work so we can determine if it's easier to fix or install Sun, or that I can use to force our desktop configuration team to update the company policy on the MSJVM.
Thanks
Update 2009.10.19: It's clear that something disabled the MSJVM. We should reject users who are using that JVM but it hasn't been a priority to update the site. We've just been waiting them to fail and then directing them to install SUN.
Most likely the Java version used by your applet is superior than the one supported by the MSJVM.
I have followed your link but I could not find what that version was. I think is something previous to Java 1.2 ( like java 1.1.17 or soemthing like that )
If you happen to have an error message or a screenshot, troubleshooting would be easier.
But, yes, the definitive answer would be to use the latest version of the Java plugin.
I remember there were scripts ( javascript ) tha help to identify the Java version and provided a link to download the latest one, but I cannot find it now. Take a look at java.sun.com and see if you can find it.
Microsoft's JVM was never Java-compliant: http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine
The MSJVM never got beyond Java 1.1.x, which is very old. So any functionality which appeared with Java 1.2 (Java 2, as it was called), such as Swing, won't work. With the MSJVM, you're pretty much limited to AWT for the UI.
Licensing issues and lawsuits triggered by incompatibilities introduced by Microsoft (such as the delegate keyword) meant that Microsoft never took their JVM further.
As of July 30th 2009 I think it was after being extending numerous times the MS JVM is finally no longer supported and at end of life.
A workaround I have seen used before if you absolutely cannot rewrite it would be to use a custom VB script to launch the application, The script would do a quick change on the registry to make MSJVM the default when the app was launched then swap it back to whatever the setting was for normal operation.
i.e.
Set Registry for MS JVM as default
Launch Application
Reset Registry for Sun JRE 1.5.0_X as default.
I dont have the code handy, you should be able to find VB registry modification with a quick google. I can probably dig it up if your stuck.