I need to write a Java web applet (if this can't be done via web applet can it be done another way?)
It's been a long long time since I've touched Java so sorry if my terminology is wrong, I'm going to have to relearn it, but before I invest serious time in it I want to know if what I am aiming to achieve is possible.
I need to be able to:
Access ICC profile on users computer
Read ICC profile data
Utilize an SDK for some specialist hardware
Can Java do this?
In short you can use Java to do just about anything (especially with a signed Applet, if you want to use Applets that is), it gets easier if the third party entities you're dealing with have a Java API you can utilise or a std way to interact with them (web servicesm, RDMS et al).
You can call out to native SDKs using JNI as well. I assume you can access this ICC Profile via the SDK call?
But overall should you use Java in this case? I'd need to see answers to my questions first :-)
A signed applet can have full system access after being installed and complete almost any task.
Related
I'm a pretty skilled java programmer that has dabbled in web development but I find that I'm much better at doing desktop based stuff than I am at anything related to web development. I've been trying to find an easy way of porting some of my desktop apps to run in browser but can't seem to find anything. I guess what I'm looking for is something similar to an applet but they a largely unsupported and get more buggy by the day. Is there anything similar that would allow me to keep my desktop style mindset and still run in browser or should I just break down and rewrite the whole thing in rails or another common web platform.
Java WebStart has been mentioned by others - It's a technology that aids redistribution of Java applications that then have the full rights of desktop applications, but they also have auto-update support built in. It's basically a launcher that fetches a JAR from the internet and runs it as a desktop application. These don't run within the browser.
Applets are an old technology that can be embedded directly into the web-page. They are not buggy, but they have several security restrictions. Also, the support is steadily declining because of the amount of critical bugs found in the technology. Desktop users that want applet support typically don't have trouble ensuring it, however. Currently, both the Chrome and the Java platform itself issue a warning before an applet is allowed to run - and that assumes the Java Runtime Environment is already installed.
Google Web Toolkit is a framework that allows creating single-page applications in Java, which are then compiled to Javascript. GWT handles multiple things behind the scenes, including server-client communication, localisation and internationalisation, and its own layout engine.
When translating an existing application to GWT, you need to:
separate the code into a part that runs on the client and a part that runs on the server. The server does not have direct access to the user, and the client does not have direct access to the database. If your application does not use centralised storage, it probably can run entirely within the web browser. Since client-server communication happens over the internet, you should reduce it to the minimum.
translate the front-end to GWT widgets. Forget Swing or AWT - they are impossible to compile efficiently to Javascript.
remove dependency on other Java classes that the GWT does not know how to translate into Javascript in the client part of the application. A large part of java.util. is supported but none of javax. (as of Jan 2014). The GWT site hosts the list of supported Java classes. Also, Javascript's regexes are less powerful than those of Java. Lookbehinds, in particular, are not supported. The server-side is a full-blown Java environment, but remember - you want to reduce the server-client communication to the minimum.
But, the most common strategy is to code the client side directly in Javascript.
Javascript is a language very similar in syntax to C/C++ and Java. It uses curly braces to denote blocks of code, and it uses semicolons to separate statements (though Javascript features automatic semicolon insertion, sometimes it understands two lines as a single statement if the first line is not terminated by a semicolon. Its data types include numbers (double-precision floating point), strings, booleans, two types of null, plain objects (which are basically hash-maps [string -> x]), arrays (untyped and dynamically extensible), regexes and functions (named or anonymous), all of which have their own literal syntax.
When coding in Javascript, your mindset should be:
Javascript is single-threaded and event-driven. You don't have to worry about concurrency issues, but you cannot say "now wait for x" either. Since Your Java code should be event-driven as well, this should not be an issue.
Lots of things in Javascript are asynchronous. Want to know something from the user? You should paint a dialog, and attach event handlers to its components. Want to get the user's GPS position? Ask for permission, passing it an event handler for when the user decides if the permission should be granted, from which you ask for the position, which also takes an event handler as an argument. Talking to the server? Asynchronous. Do you want to display something before doing a long calculation? You have to actually wait a little before you start computing. Ecmascript 6 improves the syntax a lot, but it's not yet supported in modern browsers.
Browsers only let you do so much. Disk access? Only to a file or folder the user explicitly points to. Clipboard access? The only reliable way is copy/paste into a textbox. Talking to a foreign webserver? Only if that webserver explicitly lets you (and lot of them don't even know how to). Of course, "foreign" includes a different sub-domain, different port number or a different protocol (http:// or https://). Desktop notifications? Geolocation? Ask for permissions first. Java applets have comparable security restrictions, and for the very same reason.
In Java, everything is a class. In Javascript, you can enjoy bare functions without any class. A typical event handler is just an anonymous function that you pass as an argument to a library function. Also, you can have anonymous objects using a very conscise syntax. This makes Javascript code much denser than that of Java and with very few classes, if any. Object Oriented Programming is still possible in Javascript, but much less pronounced.
When layouting your display, you need to think in terms of HTML and CSS. The best approach is to modify only the document structure (adding/removing elements or HTML classes) using the Document Object Model (DOM), and leave all CSS in an external file. In any case, you need to know CSS enough to be able to layout your page. Modern browsers support canvas, but it has no built-in layouting engine - its closest Java relative is JCanvas - just a blank area where you can draw graphics primitives - or a WebGL canvas - where you can place triangles in a 3D space.
When designing your own API, you need to know which operations might need to be asynchronous. If they are, either take a function as an argument (a callback), or return an object that does (a promise).
Except for the this variable, Javascript is function-scoped and lexically scoped and has closures. If a variable exists in a surrounding scope, it can be read from and written to - even from within a function that is only defined in that scope and called much later. In Java, you can't close over non-final function-local variables.
However, you need to be careful about timing - don't think you can just assign to a variable within a callback and use it outside. When you try to use it, it won't have been assigned to yet. Many have tried to cheat the time this way, and failed.
When the user leaves your page, it's a game over. If you want to remember anything past that point, you need to store it somewhere, be it cookies (very little space, outdated API), localStorage (decent amount of space, not supported by very old browsers) or the server (lots of space, but talking to the server when your page is being shut down is tricky).
the DOM API is often criticised, but there are several frameworks and libraries that ease the usage of it, of which the most popular is jQuery, which also handles browser inconsistencies, improves the AJAX API, event delegation (you can't attach an event handler to an element that doesn't yet exist) and includes an animation engine (though modern CSS is almost as powerful and often easier to use).
I think java web start could help you
http://www.java.com/it/download/faq/java_webstart.xml
I suggest you to take a look at Java Web Start. It offers you a possibility to start your application software for the Java Platform directly from the Internet using a web browser.
For more details see: Java Web Start
Nowadays Web Start is not a good option since, the user needs to have JVM installed and with all the vulnerabilities buzz around Java is more difficult to convince users to download it. The latest versions of JDK 1.8+ include scripts to pack your application along the jvm runtime in just one installer: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/
For using your application in a browser like an applet, you can use Bck2Brwsr or TeaVM both can run java applications in a browser without Java Plugin. Bck2Brwsr also uses Java Plug in if it is available.
You can also use GWT to compile your Java application to JavaScript. Note: Swing is not supported.
Regards
My JEE app runs under tomee and allows the user to write his/her own scripts and run from a web gui, but I'd like to restrict certain operations such as System.exit(1) for example.
A discussion related to this issue can be found in the beanshell2 forum - check this out - http://code.google.com/p/beanshell2/issues/detail?id=15
Any scriptable language that works from within the JVM is OK, but I need this level of control. My first attempt was using beanshell, but it seems, as we can see from the discussion above, that this is not an option.
I would like to avoid more esoteric languages since the end user is technical, but I can't ask him/her to learn an unknown programming language just to write a script :-) [or maybe I can, if I don't find any useful option for this]
How can I get that? Groovy? Any other JVM-based script language maybe?
Groovy has a lot of power in CompilerConfiguration. You can choose the usable imports and a lot of other stuff. Allowed stuff can be whitelisted or blacklisted using SecureASTCustomizer
I used Rhino a long time ago. It allows run JavaScript into a Java App (or server side). You will probably need to manage security issues manually.
Not sure this is what you are looking for, but it can help: https://developer.mozilla.org/en-US/docs/Rhino
I don't know if I've been looking at the wrong place but it seems the documentation for this is very limited on the Oracle website. (Even on google)
I'm working on a school project in which we have to make a software in java and embed it on a micro controler. The program is never actually going to be put on a microcontroller though, we just have to develop it.
I've been looking at the Java SE Embedded, ME Client and ME documentation for the better part of 2 hours now and I still have no idea where to start.
Here's what I need to do.
I would like to develop it in eclipse preferably because it's connected to our repository. (we could use netbeans if it's not possible with eclipse)
We need a way to load the software on a microcontroller. (like an eclipse plugin)
We need to be able to run the program on a UI that we will code to test it and to show our teacher that it works.
We almost had it going with the Java ME Embedded but there is no way to make a UI to test it.
If someone can give me a link to a tutorial or anything would be much appreciated.
Thank you
+++++++++
Edit
+++++++++
I need to specify that we can choose any microcontroller or any range of microcontroller.
Does this need to run directly on the micro or can there be an OS? If you are allowed to run an OS then take a look at the beagle board which has several JVMs available (See http://elinux.org/BeagleBoard#Java)
For a lower cost alternative, Raspberry Pi offers a JVM as well (See http://www.raspberrypi.org/archives/4920)
Both the boards I've listed above are well supported by the community so you should be able to find lots of information by utilizing your favorite search engine.
If you need to run java directly on the CPU, then it appears your options are more limited... A quick search turned up a company called ajile systems who make a CPU module which can directly process java bytecode.
We're designing an app that will run on Windows, OSX, iOS, and Androids. It would be really nice to at least have most of the code in a single language rather than having to use Objective C for the Apple versions, C# or C++ for Windows, and Java for Android.
We were looking at Flex (with all of its problems) as a way to avoid having to use a different language for each version, but Adobe has thrown in the towel and in the long run that's not going to do the job. Java used to promise to be universal, but it looks like Apple no longer supports it as a part of the distributed OS, and as far as I can tell Microsoft never supported it. We don't want our users to have to download and install something just so they can use our app.
Is there a solution? Or are we stuck with building the app in multiple languages?
HTML + css + JavaScript!
Run your app on a standard web server. All of the above have standards compliant web browsers, all of the above support JavaScript and AJAX. The only thing that really varies is screen size and this can easily be dealt with by using a custom .css file for each target browser.
You could host a web application on a server and use the app browsers to interact with the application.
Although not a native application, all devices would be able to use it.
The downside is that server connectivity would be required, however this may not be an issue.
"global" languages are most likely to use virtual machines, so you can't escape the "users have to have to download and install something just so they can use the app"... I think Java is your best bet if you don't want to deal with problems of languages that compiles into native machine code.
You could use C# on all those platforms:
"Normal" .NET on Windows
Mono on OSX
MonoDroid on Android
MonoTouch for iOS
(If you ever wanted to write an app for Windows Phone 7, you'd be fine there too.)
Of course the UI part will have to change significantly between different platforms, and I doubt that it'll be particularly seamless, but it's worth considering at least.
i am not very sure, but i have heard python is a universal language. I have tried this with both mac and windows, not sure about the other plactforms
I believe C++ code can be run on all those platforms: Windows has full support for it; Android has NDK; and you can use Objective-C++ on iOS (and I assume OSX as well!).
I wouldn't go so far as to claim it's the best option, but I figured it was worth mentioning.
Ultimately a lot will depend on the nature of the app you are developing. If it's a large app I'd strongly suggest doing some detailed consultation with someone with experience in the area: because of the vagaries of the different platforms, this is one area where experience counts for an awful lot.
There are multiple options, depending on your app requirements:
First, Web app, as many said before. It is the same as the greatest common divisor - very small
Second Build the core of your app in c/c++, and for the interface use a framework that fits your needs. These suggestions are really, really great. You can even develop the interface separately for each platform, in Java for Android, Objective C for iOS, etc
Do not forget that never, ever you will be able to make the same code run on all platforms. There will always be some part with #define MAC or #define ANDROID. It's just impossible to run identical code, even for the simplest app.
Unless is a
void main(void){}
Even a web app will have a code like
if(browser()==Safari) {}
else {}
I think the answer depends on what kind of app you are going to build.
If it's like twitter, a good web interface is the answer. Each client just need to handle the GUI work, with the platform's own language and lib.
If it's a game, no communication with server. I prefer C and a script such as Lua to build the core of your app.
"Is there a solution? Or are we stuck with building the app in multiple languages?"
No, no solution for this. We use different languages because they run in different platforms. Universal languages, such as HTML, have lots of constrains because to be universal you must cut all the differences. It is the intersection set of all platforms, which is very very small .
Using HTML and Javascript is likely to be the best approach. Another option which runs on these platforms is Java FX 2.0.
Thinking outside of the box here...
What possible basic approaches could be taken in an effort to create a Flex component that could run Java?
I know I can easily use flex to browse to or launch a Java app, but there are things I can only do if I can run the Java from WITHIN an MXML Component.
I the strictest sense, I know it's not impossible (ie: if you had all the source code for flex and for the jvm), but what's the least impractical means to this end?
Edit:
Lots of people are interested in the reason WHY someone might want to do this. I see it as irrelevant to HOW to do it, but here goes: I have over 100 proprietary pixel-reading windows programs that I could port to Mac in this way, much easier than any other way. But instead of arguing the premises, the winning answer will ignore the reasons why, and focus on the HOW.
Showcase your creativity.
This sounds crazy insane to me. My answer is to not go down this route. It may be a fun technical challenge for fun; but has little practical value that I can see.
Answer the question, Why would you want to run a JVM inside a Flex app?
Also, How would you use a Flex App to browse or launch a Java App? As best I understood, the security sandbox of the browser prevents you from launching other local applications.
I don't believe you are correct about not being able to accomplish certain things you "can only do if I can run the Java from WITHIN an MXML Component". With proper communication set up, you can have the Applet and the SWF simply communicating with each other through an external set of processes.
The easiest way to accomplish this is to "fake it". Load a Java Applet (This should be possible by use of the SWF's ExternalInterface API -- generate the Object tag and add it to the HTML around the swf. To make this even more convincing, use CSS to have to Applet appear "on top" of the swf. ) and have it communicate with the original swf through JavaScript calls. If that is not possible, then it may be possible to have the Java Applet generate some form of pseudo-server which the swf could then communicate with.
If neither of those work, then there is always the SWF bytearray syntax. It would need to load a ByteArray, manipulate the internal data, and then send it... somehow.
A while back I prototyped something like this. I exposed a window / native app via a VNC server and then used an open source VNC client library to connect to the VNC server. It was totally hacky but it worked. Performance was not great but was usable. Here is the Flash VNC client library I used:
http://www.wizhelp.com/flashlight-vnc/index.html
I'm with Flextras, you need to explain why before a reasonable solution can be proposed.
Unreasonable solution:
Implement the jvm in AS3. Read jars in as bytearrays. Pass the bytearrays to you new jvm.
Reasons for unreasonableness:
Implementing even a partial jvm would be at least thousands of man hours of work.
Running a virtual machine inside of Flash's already (relatively) slow vm would be like riding a golf cart that's being towed by a tortoise: either one by itself would be faster.
You can interface between Air & a Java app using merapi (although that's just communication, not actually running the api inside air)