I have some Java user interface controls that I want to host in my .NET application as I can't afford to rewrite them. How can I do that? Do I need to wrap them up in COM? How do I do that? I want the component to sit on a form with other components written in .NET.
If you're using VS2005, have you considered compiling said Java component in J#?
I've never tried J#, but I seem to recall Microsoft claiming that it would convert Swing calls to their WinForms equivalent.
There's no way to force this high level of integration; you cannot make a .NET form host a Java component. Even COM wrapping wouldn't get you the level of integration necessary to host the component in the form.
Conceptually I find it almost impossible to believe that it is possible to do this.
However, you might try migrating the existing components to J#.
There's a product called JNBridge that claims to do this - I've never heard of it before.
See also, this previous post.
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
hi every one there please i need some info
i have created app using directshow &c++ for image processing
so the thing is that i need to create a sophisticated GUI i have used win32 components which don't fulfill my needs and my expectations plus difficult to tweak specailly with events
so i got to find a solution i thought about using jni and merge c++'s functionality with java's the swing components .
the other choice is to use the window form(.net) but if i'm right i need to use directshow.net (i don't know how to use it )
Qt is most often called the best C++ framework for building GUIs.
Windows Forms is quite nice. Don't be afraid of using DirectShow.Net, it looks very similar to C++ but easier. You can take a look at GraphEditPlus, it can generate DirectShow graph building code in both C++ and C# (for DirectShow.Net), so you can see how semantically the same code looks in two languages. Also, GraphEditPlus itself is an example of Windows Forms application working with DirectShow.
"but if i'm right i need to use directshow.net".
No, not really. You can create an activex control in C++ that wraps your current code and use that instead in .Net with Windows.Forms.
Does anyone have links and resources to connect to an AS400 from Java?
I remember years ago, somebody told me about a connector that simulates KeyStrokes from the keyboard and other "purest" approach that connected directly.
On the web I have found a lot of links, but I cannot find a complete product to do this (I am probably not using the right keywords).
EDIT
Thanks for the answers:
What we are looking for is a way to access the data inside the AS400 and/or the screens it uses and expose them for other new applications re-use. Either as a webservice of some sort, or directly through Java ( and java will expose the operations using webservices )
Thanks in advance.
EDIT
As per MicSim post, I've also found this link:
http://www.ibm.com/developerworks/library/ws-as400/index.html
What you are looking for is probably the Toolbox for Java™ & JTOpen from IBM. There is also an AS400 class in the toolbox for performing specific AS400 tasks. You can look here and here for more details. Just googled it and hope it's helpful.
IBM's 5250 screen-scraping technology was "WebFacing" - I would post a link but you're probably better off Googling it, since IBM's documentation is so scattered. There are other technologies available too but: Screen-scraping was never anyone's favourite since typically you end up with something which, although it looks more up-to-date, actually is harder to use than a green screen and no more functional. The 5250 is probably the single best data entry platform I've ever used - web forms in a browser are one of the worst.
As mentioned, jt400 is the way to go for most other things. In particular:
JDBC - for all things SQL. If you do it right and address your files as though they really are tables, it's a way to get away from the 400 entirely.
Record-level access - write Java programs using a similar database API to RPGLE (all those chains, setlls that 400 programmers love)
Call programs, system commands, manage resources (data queues, data areas, prints / spools, jobs etc etc)
Good luck
If you just want to run Java on the AS/400 (or iSeries, or System i, or whatever IBM's marketing department has decided to call it this month), that's a supported language. You can access the pseudo-DB2 database directly. Or are you after some other form of integration?
This obviously depends on what you want to do, however if you want to simulate keystrokes across a network connection to an AS400 process then Expect4j may be the library you are looking for.
This is generally a really nasty hack though and there are frequently better ways to achieve your goals. What are you trying to do?
The expect4J library can be found here. Expect was originally a unix command that allowed you to specify a string that you are expecting to see and then a string of characters to return. It was frequently used for automating logins etc and for screen-scraping applications.
Even better is the TN5250j Console, which can be used to extract data from the AS/400.
jacada makes tools to do what your looking for
http://www.jacada.com/
Is it possible to easily embed ActiveX controls in Java application? Is it worth it. In my next project I should either use existing activex in Java app or have to reimplement everything from scratch, so I'm wondering what will be less hassle.
I don't think there's a way to do this without resorting to a third party library. (Or rolling your own, but you did say "easily".)
SWT (The "Standard Widget Toolkit") contains support for embedding ActiveX controls. SWT is an alternative to Swing, though there is a degree of interoperability between them.
Here's an example of embedding Windows Media Player in an SWT window.
Alternatively there's the Jacob project, though I haven't used that myself.
As for "is it worth it?" Well, I can say from experience that SWT makes it relatively easy, but unless your application can gracefully deal with not having them available, by relying on COM components you are losing the ability to run on multiple platforms that makes Java attractive in the first place.
It really depends on how much you are going to have to re-implement. The Jacob project is quite good (we use it extensively for automation of Excel and Word), but you have to really understand COM to use it, especially the vagaries of the IDispatch interface (very few people who use ActiveX / COM actually understand COM - they just rely on Microsoft's template generation).
If you are just trying to save yourself some typing for some simple DAO objects, you'll probably be better off re-implementing (heck, you could probably take the DTD and write a script to generate Java code for it).
http://www.codeproject.com/KB/cross-platform/javacom.aspx?msg=1776281 might help if you're willing to do stuff by hand...
Doesn't seem quite as flexible though...
My goal is to get Limewire(JAVA) and Songbird(XULRunner) to run together.
I was thinking the best way is to run the XUL application(songbird) inside a JAVA swing panel. Is there another way?
Would it be better or possible to have the GUI entirely in XUL, and then access my JAVA objects somehow?
How would I go about doing this?
Thanks
Take a look at JRex, as it might let you peek into a couple of ideas.
Other than that, I'd also research about Rhinohide as well.
Take a look at DJ Native Swing, a native Swing implementation using SWT and Xulrunner.
I am currently researching XUL for a new product and I came across JavaXPCOM which allows Java code to interact with XPCOM objects. I'm still wrapping my head around the Mozilla stack, but from what I understand all XULRunner applications use XPCOM. Therefore, it seems like you should be able to embed Songbird with this approach.
The official XUL implementation by Mozilla and is heavily dependent on Gecko.
Gecko is not written in Java nor embedded in AWT/Swing/SWT (at least without using JNI).
So, the short answer is: no. You must either use JNI or use heavy, complex and incomplete third party libaries.
However, JavaXPCOM seems to allow embedding Gecko: https://developer.mozilla.org/en/JavaXPCOM
But in that case you'll depend on Gecko... and I don't know if that's enough to run Songbird.
I would examine Limewire's source code. If there's a clean separation between UI and the rest of the application, I would try finding a solution to instantiate and invoke Limewire's non-UI code from within a Songbird extension.
I would take a look at eclipse swt's embedding of
xulrunner:
http://www.eclipse.org/swt/faq.php#whatisbrowser