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.
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.
I have an assignment where i need to write a Java program that parses a .class file and retrieves things like :
1.name of the .java file
2.implemented interfaces
3.variables
4.constructors
5.methods
I don't have any ideeas where to begin from?
For example,what kind of Data I/O structure should I use?
You can you ClassParser which is available in Apache commons library. you can read the Javadoc here. You can download apache commons from here
You can also use Java reflection API which provides method such as getDeclaredFileds, getDeclaredMethods etc.
There are already several libraries for classfile parsing out there. Objectweb ASM is the most popular.
If you have to do it from scratch, that I'd recommend starting by the JVM specification, which explains the binary layout of classfiles in detail. After that, parsing is just a simple matter of programming. I've written a classfile parser before, it's not that hard.
You don't need any external library, just use java.lang.Class. Write the name of your class:
[NameOfMyClass].class.getDeclaredFields();
[NameOfMyClass].class.getDeclaredConstructors();
[NameOfMyClass].class.getDeclaredMethods();
It's the same for interfaces and many other attributes.
You can use Java Reflection. Here is a good tutorial -->
Java Reflection Tutorial
OpenJDK actually comes with an API that lets you parse and manipulate class files programmatically that most programmers don't know about. It is located at the package com.sun.org.apache.bcel.internal.
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.. :-)
Java 7 introduced a zip FileSystem. The link below illustrates how to create a zip FileSystem from a zip file.
http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html
However, I can find no example of how to create a zip FileSystem from an InputStream. Is that possible? If so, how?
Note: I know I can write the InputStream to disk and create a zip FileSystem as described. I consider that a hack, and I would prefer to avoid it.
No, it's not possible because the file system requires random access to the ZIP file.
Shameless self-plug: You may find TrueZIP easier to work with and more powerful. However, the same constraint applies to it, too.
Only a partial answer, but I expect you'll need a custom file system provider and this question about an in-memory file system might help. Note that the newFileSystem documentation shows a memory://... URL scheme, but no more detail.
As pointed out in another answer, the file system requires bidirectional access to the data, so this assumes enough memory to load it entirely.
I would like to write toy IDE for Java, so I ask a question about one particular thing that as I hope can help me get started.
I have editor implemented on top of swing and i have some text in there. There is for example:
import java.util.List;
Now I need a way to send "java.util.List" string to a method that returns me all the information I may need including JavaDoc document.
So is there any tool that can set up classpath with libraries, that would parse every string I send and try to find if there is any Class/Interface with documentation to return?
So is there any tool that can set up classpath with libraries, that would parse every string I send and try to find if there is any Class/Interface with documentation to return?
AFAIK, no. There is no such free-standing tool or library. You will need to implement it yourself. (Don't expect that writing a Java IDE is simple ... even a "toy" one.)
Libraries will have class files, which will not have javadocs.. So it is not clear what you want to do.
There are many byte code engineering tools to analyse and extract information from class files. For example asm or bcel. Javassist allows to process both source and byte code, so may be close to what you need.
You could use html parser to get the javadoc and other info from the web using the full path to the class (including package names to construct the correct URL per class). This will of course depend on the version of java you are using.
You can also use the javadoc tool from within java to generate the desired documentation from java source files (which can be downloaded from the web). The source code of the tool could also help you out. See http://java.sun.com/j2se/javadoc/faq/#developingwithjavadoc
Lastly, if you need information based on runtime types in your program, you might want to check reflection capabilities.
First you need to know How to print imported java libraries?. Then download java API documentation here. Once you find out imported libraries, open an inputStream in order to read appropriate HTML file.
Beware! This technic will only work when importing from jdk.