I want to use a javamoney lib, I found two lib the below:
javamoney/jsr354-api and javamoney/jsr354-ri in the github. What's the diffirence, thank you.
ri in jsr354-ri stands for reference implementation, and api in
jsr354-api stands for the programming interface without the implementation.
You'd use api to program against and implementation is needed runtime to actually execute your code. Reference implementation means it's the "official" implementation version.
Related
Assume that I have a simple servlet program which requires only the web container. Also assume that I am not using an IDE to compile this program. I can compile my program as follows.
javac -classpath /path/tomcat/common/lib/servlet-api.jar -d classes src/Ch1Servlet.java
I have been said by some people that servlet-api.jar just contains the specification, and the implementation is provided by the tomcat server. This confuses me.
If I compiled a program using a library, I still need the same library when I am running the program also. Therefore at some point Tomcat has to use the same library specified above (servlet-api.jar) when running the application.
What is really meant by implementation and specification? What makes a code just a specification? An example in code would be really helpful.
A library contains declaration - Interface which fixes method. E.g.
public interface SaveInterface {
void save();
}
You use the interface to save your data but implementation could be different. Tomcat saves the content here adn another application there. All depends on real implementation. But you in your logic don't care how it's implemented. You use the interface.
Interfaces/Abstract classes contribute to a spec and the actual implementation of it is what is used by us as the implementation.
I'v got a library, which uses sun.awt.geom.Curve class. I found no such class in standard JRE. How to use it? May be it is possible to replace this class with some public one?
Classes in sun.* packages are part of the implementation of the runtime and should not be used directly because they may change from one release to the next without a warning. You can see the documentation and source code of sun.awt.geom.Curve from OpenJDK for example here: http://www.docjar.com/docs/api/sun/awt/geom/Curve.html
Whether it's possible to replace it with something else depends on what the code does with it.
SLF4J has a nice mechanism, where the implementation is chosen at runtime, depending of what is available in the classpath. I would like to use such feature in several projects, for example to choose the communication layer or to choose a mock implementation.
I had a look at slf4j source to see how it's done and I could just write something similar. Before I start, I would like to know if some lightweight FOSS library exists for this kind of injection.
Unless you need specific configuration abilities as provided by Pico or Guice, you may get what you need from java.util.ServiceLoader.
Basically, all you have to do is to package your service implementation in a JAR file, include a text file with a list of all implementation classes in "META-INF/services/" and on you go.
Have you looked at Weld, CDI is part of the EE6 spec but the Weld implementation also supports running in a Java SE environment. It has exactly what you are looking for, here is a link to the relative documentation:
http://seamframework.org/Weld one maven dependency for your SE app.
http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/environments.html#d0e5333 bootstrapping the Weld container in SE.
Producer methods to vary implementation at runtime:
http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/producermethods.html
Plus (in my very biased opinion) Weld rocks ;)
SLF4J's "mechanism" is simply that its API jar is compiled with code that refers to a class that is only provided by one of its "implementation" jars. No framework or library of any kind is needed for this. Simply write one module which is compiled against a class not in that module. Then your "implementation" modules provide that class when included in the project.
Edit: Oh, and this is basically OSGi writ small (very, very small). If you're going to use this kind of thing on a large scale, look to an OSGi container or Eclipse Virgo.
Every java programmer should know how to use Spring.
I am quite new to Java, and need to work on a project requiring using open source software. I am very confusing about understanding those Java API's documentation.
As an example, can you show me how to use the related java class, RemoteXmlSimpleSearchEngineBase, based on its Java API.
Please refer to this link
http://download.carrot2.org/stable/javadoc/org/carrot2/source/xml/RemoteXmlSimpleSearchEngineBase.html
I am very interested in this derivation process, so that I can use other java classes based on reading its API documentation. Thanks.
Often the JavaDoc doesn't explain the general concept of a library but just the API for that class. It might contain more useful information (like the JDK JavaDocs do), but in general you should try to get a user manual, reference or getting started guide.
From the JavaDoc you can still learn a few things:
what interfaces are implemented
which directly known subclasses/implementors exist
you see that the class is abstract
which methods are added/overridden by that class
which methods are added
pre-/postconditions of the methods and its parameters (sometimes not listed)
...
However, you often don't get the general concept or when a method is called, how to configure a class for various use cases etc. You simply can't put that all into an API documention.
Maybe you should take a look to the project documentation:
http://project.carrot2.org/documentation.html
You have some examples and lot of information.
What I often find useful when trying to get an overview over some API are the class/interface trees, and even more the "Usage" pages - they show which other classes/interfaces use this class/interface in their API. This shows how to get some type of object (by finding return values), or what to do with some object (except from using its methods itself).
Sadly, the latter ones are not generated by default (and also missing in the example in your question).
Very often, the JavaDoc overview page will have some overview of the API and code examples. This is actually the case with Carrot2 JavaDoc:
http://download.carrot2.org/stable/javadoc/overview-summary.html#overview_description
I am using jaxb (xjc version "2.0-b26-ea3")
I have been able to generate the classes for the schema (.xsd) using xjc but however when I try to compile the generated classes I get errors saying... "Package javax.xml.bind.annotation" doesnot exist."
I am using jdk1.5.0_14. I am trying to run through command prompt.
Any help will be appreciated.
Thanks in advance!!
XJC-generated Java source files use annotations from the JAXB API. In order to compile them, those annotation types must be on the classpath.
To use JAXB (for marshalling and unmarshalling to/from XML documents) you'll need these things:
The JAXB API definitions.
A JAXB implementation.
Any libraries the implementation depends on.
An implementation is separate from the API and interchangeable. It will be located via the Java service provider mechanism. I won't go into the details of that here, but let's say it should be sufficient to have a jar with an implementation on your classpath. Normally you'll only make calls to the JAXB API classes. For example, JAXBContext.newInstance("my.sample.pack");.
The actual implementation is located at runtime and loaded through your API calls. This means that in order to compile JAXB code, a jar with the API should suffice. An implementation and its dependencies is only required at runtime.
Now for a JDK 1.6.x, you won't need to include anything additional on your classpath. Starting with Java SE 6, the JAXB API was included in the standard Java SE API. The Java Runtime Environment also includes an implementation of that API. This is the Reference Implementation available on the java.net JAXB site.
For JDK 1.5.x, things are a bit different. The JAXB API was not yet included as a standard Java API. So you'll need to make it available manually. At the very least you'll need the API; the implementation you're going to use is free to choose, although I don't know any besides the reference implementation from the top of my head. It is probably the best one to start with.
Click the "download now" button on the JAXB site linked above. You'll see a link to download a jar file. Get that and open it either by double-clicking it in your file system or running it via the command line. This will extract some content to a folder in the same location as the jar. You'll see a number of folders. The bin folder contains runnables for xjc and schemagen. There's also documentation and sample folders. The lib folder is the one interesting to us. Here's a rundown:
jaxb-api.jar: this is the JAXB API; you'll need this for compiling your generated code
jaxb-impl.jar: the reference implementation; not needed for compiling but you'll want this at runtime
jaxb-xjc.jar: useful for invoking xjc programmatically or in Ant
jaxb1-impl.jar: the reference implementation of the JAXB 1 API; I assume you'll stick to JAXB 2 so ignore it
activation.jar: a dependency, not needed for compiling but might be needed at runtime
jsr173_1.0_api.jar: this is in fact the Java Streaming API for XML (StAX); it is used by the JAXB reference implementation
That last one works like JAXB in terms of implementation. It is an API with interchangeable implementations. And just like JAXB, it's not available by default in Java 5 but was included in the Java 6 API. You'll probably need an implementation for this as well in Java 5. I leave you to find and use it; the steps followed will closely ressemble what I described for JAXB.
So, to wrap it all up in a concise overview... If you can use Java 6, pretty much all dependencies are available out of the box and you won't need any additional stuff on your classpath to compile JAXB-related code and run it. For Java 5, you'll at least need the JAXB API for compilation and the API plus an implementation at runtime. The implementation might have some dependencies of its own, so if you're still getting ClassNotFound errors, try to find out what project the missing class is a part from.
The jarfinder site suggested by Pangea can be very useful for this. But don't skip the step of checking the actual project site to make sure you get all dependencies, the latest version and see what the licensing terms are.
Good luck!
That package is part of jaxb 2.0 api. you can download it here. These kind of questions can be easily self answered with the help of http://www.jarfinder.com