Hello, habrazhitel!For several years now, having worked on various desktop Java applications and once again digging through my deposits of useful libraries, I realized that the time had come to structure the entire accumulated collection a bit and discard the superfluous. At the same time, I wanted to isolate the most rare specimens from it and add a small explanation to them (what, where and how it works) in order to use the necessary part quickly and easily, if necessary. Actually, I wanted to share information about some of the most prominent libraries in the collection with you - what if it turned out to be interesting or even useful to someone.
So, today I will provide libraries here that can help you solve frequently asked questions like “How to do it in Java?” In various narrow areas of development.
')
I’ll say right away that most of the libraries listed in this article use native tools to implement this or that functionality. But this does not mean at all that they should be immediately abandoned. However, I will not breed holivar and immediately go directly to the topic ...To choose or not to choose?
I think in many applications there is a need to select / open / save a file from / to the file system - this is probably one of the most widely used parts. Standard tools for J2SE offer for this your cross-platform tool - JFileChooser. By itself, it looks more or less, but it differs from the native dialogues that your operating system (hereinafter OS) offers you. In addition, under Linux and MacOSX, it is a kind of “knee” solution, which is not at all clear how leaked (and is still present) in recent versions of the JDK.
There is also another standard option - AWT'shny FileDialog. On Windows, it is almost identical to the standard file selector, but on other operating systems, it completely gives up its positions and is even worse than JfileChooser. So what to do?
Here comes the work from Eclipse -
SWT . In their set there is a “similar” FileDialog, which, however, on each individual OS causes a native dialog for selecting files, which can be customized to your liking. Additionally, there is also a DirectoryDialog for selecting purely directories. In my opinion, if you need a quick and tidy enough solution - this is the best option. The only drawback is that you will have to drag the rather bulky SWT libraries behind you (however, your acquaintance is probably not limited to these two dialogues, then the game is definitely worth it).
There is also a little wrap over SWT directly to the FileDialog / DirectoryDialog in the
Native Swing library - I'll talk about it a little later.
Grab and run!
In some specific cases, it is required (or really want) to receive notifications in the application about pressing any keys outside the application itself. Standard tools do not give such an opportunity (which is understandable).
Using the
JIntellitype library (under Windows) or the
JXGrabKey (analog for Linux), it is possible to do this.
Both libraries are a wrapper around the added native parts and, accordingly, require their presence in your application.
Alas, I did not find any analogues of these libraries for MacOSX (even the slightest mention of their existence) - I will be happy to add if anyone brings it to her.In order to slightly dilute the text, I will give a small example of using JIntellitype:
Everything is quite simple and clear (working with JXGrabKey is absolutely similar).
There is only one caveat for using this library - if you create any hot key (for example, in this case, CTRL + SPACE) it will be blocked for the entire system. Those. only your application will receive it. At least such a nuance was noticed under windows, not sure about the Linux version. That is why I added an additional handler, turning off a certain hot key if necessary:
It is important to know that the 32/64-bit version of the JVM (namely the JVM, and not your OS) will require 32/64 bit builds of the native libraries, respectively. This is an important point, since it is also valid for all other libraries with the native part.Flash in the night
I think this topic can be quite jaded, but I will still describe the problems that I encountered while trying to run Flash movies in a Java application.
I’ll say right away that we couldn’t find a normal cross-platform solution, and the options found also do not shine with performance / efficiency. I can also add that in this area everything is much worse than in the others described in this article.So, let's go to the options.
Native Swing - yes, this library also has the ability to embed Flash into your application (implemented on the basis of SWT functionality). I tried it on Windows and Mac - the developer’s example is correctly executed on both. Under Linux, not everything is so smooth (probably due to problems with Flash plug-ins) - without dancing with tambourines, adjusting libraries in the system and setting up plug-ins will not allow Flash to run.
There are also incomprehensible problems with the paths in the presence of a proxy installed in the browser (it is likely that the browser-based Flash plugin is used for display and, accordingly, the proxy affects its operation). However, I managed to successfully launch various Flash-videos under Windows a couple of times. There is also the possibility of "communication" with the Flash-movie itself using standard library tools.
JFlashPlayer is a separate paid library that implements work with Flash-player exclusively under Windows. It works quite stable and fast. If you need to use Flash specifically for the win platform, I think it will be the best choice, since it works directly with the Flash API and does not require any additional cumbersome libraries.
Draw it ... I said draw it now!
So, in order not to linger on the “abundance” of Flash-implementations in Java, we move on to the most developed part, or rather to the libraries, complementing the list of possible image formats for opening / editing / recording. In this area - who is on that much. Many different things have been written - from small classes to entire huge commercial libraries.
So, what initially can read J2SE and what would you like to “train” it?
Let's see the list: gif (difficulties with animated gifs), png, jpeg, bmp, wbmp
What I would like: gif (animated), apng, tiff, psd (maybe something else?)
Let's start one by one ...
Animated gifs - there are a couple of problems here, the first is the ability to read individual frames (and then write them correctly) and information about the delay between them, the second is to correctly save fully transparent gif pixels of the image.
The first problem is quickly solved using additional libraries (
gif4j ,
Imagero , separate
Decoder /
Encoder ), which allow you to read / write frames and information about them.
I did not find a solution to the second problem anywhere, so I added it manually, based on the gif format specification — you need to find the unused color in the image and mark it as “transparent” for this frame of the gif, which further tells the image renderer about the transparency of all pixels with this color . However, for direct recording, I used the above Encoder.
If someone is interested, I can separately provide a working code, it's just too cumbersome to show here.Apng (animated png) is a fairly new format, but even with that in mind, there is already a wrapper to work with it (at least for reading). Actually find the code itself is possible here
JavaPng .
At the moment, the apng image format is fully capable of displaying only Firefox (3.6+), Opera (9.5+) and some individual applications because of its specifics, although images in this format can be very useful in some cases.Tiff, psd and some others - under tiff / psd and many other less popular formats, I found a single library
Imagero . More information about all supported formats is easier to read right on their home page. Most of all, of course, I was interested in PSD format support, to be precise - how wide the range of possible operations with layers / images is, what data can be pulled out, which versions of files it is possible to read / write, and so on. After some time, it was possible to find out that it is possible to read the layers, information on them (location, name, colors, etc.), read the images from each layer separately, as well as learn some other information. In principle, this is more than enough to be able to display a PSD image at the base level in your application.
The file that I checked this library was made in Adobe Photoshop CS3, so I'm not sure that the formats of newer versions will be readable.Time to surf
Now I’ll turn to one of the most acute problems - the ability to embed a browser component that can display (correctly!) Html and play JavaScript. Of course, beyond this, it is desirable to be able to keep track of the contents and do some other additional things. I also want to have a cross-platform solution (we still write in Java).
So, let's go straight to the variants of implementations that I met ...
JDIC (Java Desktop Integration Components) is probably one of the oldest solutions. From the very beginning of the library it was possible to embed the browser of the current OS into your application. Also in the library there were (and still are) many problems and mistakes. Yes, the library itself is updated very rarely (like at the moment it is already well outdated). However, in one of our old project, the browser built-in via JDIC still hangs and it works for itself. Firefox and IE can build a library (I’m not sure about the second one, because we couldn’t make it work). Works under Windows / Linux.
Native Swing - yes, again and again, this library contains a lot of interesting things, including the possibility of embedding the native browser of the current OS. It works stably and without problems under all the most well-known operating systems (Windows / Linux / MacOS) - I personally checked it on different versions. Actually, the library itself simply uses the SWT functionality and makes the various components and features a bit more human (in this case, the ability to use the browser).
Lobo Browser is another rather outdated project. The browser itself is implemented entirely in Java, but its performance leaves much to be desired. Most modern sites / applications it does not pull (just collapses when rendering pages). I think it may be useful in some individual cases, when you need to insert into the application any extraordinary pages (for example, forms with registration, or sending a letter), it is more likely that it is more incapable.
WebRenderer is one of the commercial developments in this direction. The browser itself uses the FF3 engine. With most modern sites and applications to cope with a bang. Supported OS - Windows, Linux, MacOSX and a couple of others. As for Mac / Linux, I will not say it, but under Windows I tried this option - it works perfectly acceptable. By the way, the browser is also able to play Flash-videos and Java applets, which can not but rejoice. A slightly different question arises - how relevant is it, given that HTML5 is already in the yard, and this engine only supports the previous version. Perhaps manufacturers will eventually move to a new version of Firefox and this question will go away by itself.
JWebPane - well, at the end of a bit of fiction ... For a long time (
from the distant 2008 ) release of the JWebPane swing component is expected, which should solve the problem “Where can I get a browser component in Java?” Once and for all: , support modern standards Html / JS, rendering with Swing tools and many other interesting points and features. However, on the basis of some articles and messages - at the moment bets are made on JavaFX (which some very negatively perceive), and therefore the work on this component and some other interesting areas are trivially postponed (or abandoned altogether?).
Such is the situation on the "front" of Java-browsers. Whether to take add-ons to use full browsers or “crutches” in the form of some ready-made solutions - you choose, both options have known pros and cons and tons of problems and jambs. Or you can wait and hope for JWebPane, if you are optimistic enough;)
Showtime
Well, in order to dilute a little tense situation I will bring a couple of interesting things that I found just recently, and which I would also like to share.
Along with questions about browsers, Flash and other native things in Java, they are often interested in the ability to play videos. So, consider what options there are ...
JMF - probably the first thing that
comes to mind on the subject of this issue. By itself, JMF cannot play modern video — it needs plug-ins that recognize different formats. Without them, it is virtually useless. There were a lot of enthusiasts who had completed these same plug-ins, but over time their support and updating probably became impossible or simply abandoned.
Fobs4jmf - actually when searching for those plug-ins for JMF, in due time, I came across this library, which in fact is a plugin for JMF and a wrapper for ffmpeg. However, confirming my words, the library has not been updated since the distant 2008. Even with this in mind, a sufficiently large part of the modern video can still be reproduced (I personally tried it and made sure of it), although on the fact that the JVM cannot be reproduced tightly.
Native Swing - there is also an interesting option in the collection of this library that allows you to embed Windows Media Player into your application and manage it and its settings. In this case, the potential for video playback will be limited to the codecs installed on your machine that WMP can use. And, of course, this is a Windows-only solution.
VLCJ (Java Bindings for VideoLAN) - as the name implies - this library is a wrapper to
VLC cross-platform video player. By itself, this player does not rely on the codecs installed in the system, but always has "everything with you." Accordingly, when used in conjunction with a Java application, you can be completely independent of the system, installed codecs, and some other nuances. However, to build your Java application for different OSs, of course, you need to take the necessary native libraries from the installed VLC and correctly set the paths to them when initializing vlcj:
String path = "C:\\MyProject\\lib"; NativeLibrary.addSearchPath ( "libvlc", path ); System.setProperty ( "jna.library.path", path );
Native libraries can be simply placed in your project / installer of the application and always have at hand. Then you can immediately start using the Embedded player:
Canvas vs = new Canvas (); MediaPlayerFactory factory = new MediaPlayerFactory (); final EmbeddedMediaPlayer mediaPlayer = factory.newEmbeddedMediaPlayer (); mediaPlayer.setRepeat ( false ); mediaPlayer.setEnableKeyInputHandling ( false ); mediaPlayer.setEnableMouseInputHandling ( false ); CanvasVideoSurface videoSurface = factory.newVideoSurface ( vs ); mediaPlayer.setVideoSurface ( videoSurface ); someContainer.add ( vs, BorderLayout.CENTER ); mediaPlayer.playMedia ( "C:\\video\\SomeVideo.avi" );
This is just a basic use case. There are many different settings and possibilities for obtaining information about the video being played (for example, the available subtitles, audio tracks, etc.). I think it makes no sense to write about all this - it is better to see
examples on the project website.
The speed of work and the low load on the system, by the way, is impressive. As the stability of the player. According to the developer himself, problems may arise when playing more than 3 videos at the same time, but there is also a solution to this and other small problems.
So what?
Summing up, I will list all the above libraries once again in a single list with a few additions about their use and links to the official library / project sites:
SWT (
stable ) (
dev )
License: EPL
Compatibility: Windows / Linux / MacOSX and others
Cross-platform: Yes, but for each separate OS and architecture it is necessary to use a separate set of libraries
Native Swing (
stable )
License: LGPL
Compatibility: Windows / Linux / MacOSX
Cross-platform: Yes
JIntellitypeLicense: Apache License 2.0
Compatibility: Windows
Cross-platform: No
JXGrabKey (
stable )
License: LGPL 3.0
Compatibility: Linux
Cross-platform: No
JFlashPlayer (
demo )
License: Commercial
Compatibility: Windows 98 / Me / NT4 / 2000 / XP / Vista
Cross-platform: No
Gif4J (
demo )
License: Commercial
Compatibility: All java-supported platforms
Cross-platform: Yes
Imagero (
stable )
License: Free for non-commercial use
Compatibility: All java-supported platforms
Cross-platform: Yes
JavaPNG (
stable )
License: GPL 3.0
Compatibility: All java-supported platforms
Cross-platform: Yes
JDIC (
stable |
win32 libraries )
License: LGPL 2.1
Compatibility: Windows / Linux
Cross-platform: Yes, but for each separate OS and architecture it is necessary to use a separate set of libraries
Lobo Browser (
stable )
License: GPL
Compatibility: All java-supported platforms
Cross-platform: Yes
WebRenderer (
demo (requires registration))
License: Commercial
Compatibility: Windows / Linux / MacOSX / Solaris / AIX
Cross-platform: Yes, but for each separate OS and architecture it is necessary to use a separate set of libraries
JMF (
stable )
License: SCSL
Compatibility: All java-supported platforms
Cross-platform: Yes
Fobs4JMF (
stable )
License: LGPL
Compatibility: Windows / Linux / MacOSX
Cross-platform: Yes, but for each separate OS and architecture it is necessary to use a separate set of libraries
VLCJ (
stable )
License: GPL 3.0
Compatibility: All java-supported platforms
Cross-platform: Yes, but for each separate OS and architecture it is necessary to use a separate set of libraries
That seems to be all. I hope at least a small part of the information provided here turned out to be useful to you or prompted an interesting idea or two.
All the data on the libraries and their relevance were rechecked by me for the last 2-3 days and if I made a mistake somewhere or didn’t say anything, I will be happy to add or correct it.
Update 1: Added links to download libraries (JDIC is not available for download from off site, so I posted it separately on ifolder)