I am building a java ImageIO wrapper around the OpenJPEG native library.
I have a working ImageReader implementation. However, I am unable to get
the ImageIO library to load my implementation automatically. Instead, I have
to manually register the class, and then it works.
Does anyone have any ideas on how to get ImageIO.scanForPlugins to work properly?
If you want to take a look at the code, just clone my branch from here
https://github.com/CodecCentral/openjpeg/tree/java_imageio
There are two maven projects inside: one for the reader, and one for a simple viewer
that links to the reader.
You can also find sample Jpeg2000 files here:
https://github.com/CodecCentral/openjpeg-data
You seem to be missing the META-INF/services/ resources needed for the service registry to pick up your Spi classes.
The resources are text files, and need to be named after the Spi class they implement (one for writer and one for reader), and contain one single line with the exact name of your Spi implementation class.
You need the following files (in java_imageio/wrapping/java/openjp2/src/main/resources):
/META-INF/services/javax.imageio.spi.ImageReaderSpi
# File content (comments allowed)
org.openJpeg.JP2KOpenJpegImageReaderSpi
/META-INF/services/javax.imageio.spi.ImageWriterSpi
# File content (comments allowed)
org.openJpeg.JP2KOpenJpegImageWriterSpi
Some additional comments: While not directly related to registration, I browsed your source code, and there might be some other issues with your Spi class.
For inputTypes you list File, byte[] and URL. While these types might be okay, ImageIO will likely require you to support ImageInputStream as well (most readers only support this), for normal operation. See the static read methods on ImageIO, and how they are implemented.
The canDecodeInput is supposed to look into the file/stream contents to recognize format "magic" identifiers or header structure. If you simply return true, your reader will try to decode any File, byte[] and URL regardless of content, not giving other readers a chance to properly read them. And again, I think you have to support ImageInputStream as input for normal operation.
(I assume the hardcoded JNI paths are only temporay.. :-)
Related
I would like to use a Java library in my Android application. The class constructors and methods of this library often take paths to files (configuration file, dictionary, etc.) and then build java.io.file instances based on the given paths.
In my android application, I would like to store these file in the 'res' folder (possibly in res/raw). The problem is that I have to give a path to these files to the methods of the library.
I could easily get an InputStream using getResources(), but this would not be directly usable by my library. I would have to go through all the methods taking a path as an argument, replace it by an InputStream and modify the content to deal with InputStreams instead of Files. This represent quite a lot of work and I would much prefer to use the library without modification and keep it easily upgradable.
Even though using java.io.file based on resource file would not be a good practice, is it something possible? It would definitely help if you could indicate a way to do this.
Thank you.
If the library uses java.io.File then I don't think there is a way to do this in Java (let alone the Android subset of Java). It might be possible to solve the problem with a loopback filesystem, but this depends on your Android device's kernel, etc.
See:
https://android.stackexchange.com/questions/25396/how-to-find-out-if-my-devices-kernel-has-loop-device-support
If the library uses java.nio.file.Path, then it may be possible to implement a custom FileSystemProvider that maps the resources into the default file system namespace.
Note this is for regular Java 7. It would require a back-port of the relevant NIO libraries to get this to work on Android. I had another look for a viable backport, and couldn't find one.
See:
Tweaking the behavior of the default file system in Java 7
How to use java.nio.file package in android?
There is another "clunky" way to do this. Get your application to copy the relevant resources to files that can be accessed via a File.
Updated:
My requirement is to process files with huge content. I need to apply multiple business rules on the file content. The business rule may be applicable on the whole content of the file. For example based on the status of a column, it becomes eligible for a business rule. Outcome of one business rule will be eligible for another business rule.
Another requirement is to apply quality checks on the incoming data in the form of files. In many cases, i see that i have to store large content in memory for processing.
I was going through this article which was explaining on how to process a large file using java.nio package. I found this very interesting and thought of trying this code.
Unfortunately, the code is not executable. Can somebody help me in sharing/making the executable code for this? Clues of how to make this executable are also welcome.
Issues i found are:
The method closeQuietly(InputStream) in the type Closeables is not applicable for the arguments (FileChannel)
Could not figure out what should be the Timestamped implementation (blog claims this file is not shown there)!
TrueFxDecoder and TrueFxData are missing!! A dummy implementation reference will be of great help.
Libraries used: JavaSE-1.7, Guava-17.0.jar
I believe, this executable code definitely useful to many other people who are in need of this kind of requirement.
In my experience, BufferedInputStream and BufferedOutputStream are great for processing large files, since these streams don't load the whole file into memory, they use an internal buffer. This tutorial you have chosen is quite complex and confusing.
I am looking at writing a program that can test files for corruption and/or damage. I would prefer to write the program in Java.
Now for the tricky part, is it possible to use Java to test for files corruption/damage in many different file types? I am mainly looking at checking .pdf .html and .txt files, but I fear that more files could be added onto the list soon. I honestly have no idea if this is even possible to write or not. If Java can not do this is it possible to do it with C?
I think you are going to have to take it file by file basis. For example
text files - make sure that you can read the file using FileReader
html - make sure it is a text file AND that the HTML file is valid
pdf - use a pdf generator to see if you can read the pdf and it is valid
But as alex has suggest, it doesn't matter if you do this in java. As long as you can read bytes you can check.
You also have to define corruption. If by corruption you mean correct disk blocks on the HD then you might need a lower level programming language. If you mean all the bytes represent correct data then you can do this in any language.
You will first need to define "corruption". If you can assume that a file is in good shape as long as you can open it, read its content, confirm its file permissions, and confirm that it is not empty, that's doable in java via the java io API.
If your definition of a valid file includes more rules, such as HTML files needing to be in valid XML form, and PDFs need to be correct/complete, then your program will get more interesting based on your requirements. For PDFs, you can use iText to read them and get their meta data:
http://itextpdf.com/
Files can always be seen as collection of bytes that Java can read. If you have an algorithm to check for corruption, nothing prevents you from implementing it in Java.
And using some good design patterns can make it easy to support different file types.
Acrobat has some fairly powerful repair capabilities so it repairs and opens many broken files. The spec is also quite loosely interpreted (for example TT fonts are supposed to be MAC encoded but in practise WIN encoding works).
The class java.io.FileReader not found in Java ME.
I need this in order to get the file and then parse it with an xml parser.
Anyone know any alternatives for this class?
*added
using CLDC profile. The xml file to be read is in the JAR.
That's because Java ME provides only a limited subset of the java.io package. You need to use the java.microedition.io package instead.
For actual file I/O you'll need to use the FileConnection class provided by JSR-75.
What Java ME profile are you using? The CLDC does not support the concept of files at all.
In general, FileReader is nothing but a convenience class that wraps an InputStreamReader areound a FileInputStream. It's also very broken because it does not allow specifying the encoding, and should therefore almost never be used.
It would be especially wrong to use it to read XML because proper XML data specifies its encoding, and a proper XML parser will handle that, so you really should pass binary data to the XML parser.
So if you're on the CDC profile, just use a FileInputStream directly.
the question is a bit ambiguous. I think Joachim's answer might be only partial if you are trying to read a local file. I'm certainly not sure though.
If the file is stored as a resource in your JAR, you can access it through the getResourceAsStream method in Class.
If the file is a local file on the file system and if I recall correctly, you need JSR-75 support. Over at Sun's developer page there is an introduction to JSR 75 and the fileconnection
API.
I need to ship some Java code that has an associated set of data. It's a simulator for a device, and I want to be able to include all of the data used for the simulated records in the one .JAR file. In this case, each simulated record contains four fields (calling party, called party, start of call, call duration).
What's the best way to do that? I've gone down the path of generating the data as Java statements, but IntelliJ doesn't seem particularly happy dealing with a 100,000 line Java source file!
Is there a smarter way to do this?
In the C#/.NET world I'd create the data as a separate file, embed it in the assembly as a resource, and then use reflection to pull that out at runtime and access it. I'm unsure of what the appropriate analogy is in the Java world.
FWIW, Java 1.6, shipping for Solaris.
It is perfectly OK to include static resource files in the JAR. This is commonly done with properties files. You can access the resource with the following:
Class.getResourceAsStream ("/some/pkg/resource.properties");
Where / is relative to the root of the classpath.
This article deals with the subject Smartly load your properties.
Sure, just include them in your jar and do
InputStream is = this.getClass().getClassLoader().getResourceAsStream("file.name");
If you put them under some folders, like "data" then just do
InputStream is = this.getClass().getClassLoader().getResourceAsStream("data/file.name");