Develop Reference

How to import packages from the external Library in Java?

I'm a n00b coder. I found an interesting library and trying to start toying with it. Which is not going great. This library is from 99' and uses JUnit (which I'm unfamiliar with) so there is a lot of confusing stuff. But it seems like the source of my failing even more elementary. Namely I have troubles importing packages.
This library has a test called StandardEvalTest.java. I moved to it to main Java directory and now I'm trying and failing to launch it using JUnit.
This package path org.pokersource.game.Deck goes directly from the directory where the test StandardEvalTest.java sits.
I also added the main java directory to the PATH environmental variable. Which as I assumed will allow import to locate the package.
None of those two things help. Also I was suspecting that maybe Deck.java and Deck.class are not enough and I have to do some work to create a package from it. But as far as I can say from Oracle doc the only thing needed is a package name in the header. Which seems to be present.
So I'm out of moves. Please help!
PS: Some additional info inspired by #Dhrubo 's answer:
The test I'm trying to run indeed sits in the main java folder of the library. (I moved it here hoping that when running from here it would be easier to find the package)
If I'm trying to compile the test instead of running it with JUnit he seem to fail to find JUnit classes and other JUnit related stuff.
[Oh OK I'm an idiot! Dont't mind me]

You should include the package while running StandardEvalTest.java as below
javac -cp [classpath] org.pokersource.game.StandardEvalTest.java
and run it from package root directory, I am assuming it is custom java file that you want to compile. You run directory should be parent of your package directory.
** I also see, you are trying to compile StandardEvalTest.java instead of Deck.java ... then check your StandardEvalTest.java file whether it exists in desired location.

Jpype import cannot find module in jar

I have received the task, at work, to find a way to use some methods from an existent jar file in a Python project. I have very limited experience in Python, but I have worked with that specific jar file before (it is part of a project we are working on). I am not allowed to modify much of both projects, and they are required to be as independent as possible.
I have researched multiple ways to include the jar methods in Python. So far, I have tried Jython (which I cannot use because the Python project uses PyQt among other libraries, which force the use of CPython, if my understanding is correct), Pyjnius and JPype. JPype seems the most promising, but I cannot get it working either. I have pasted the my code below, slightly censored because I don't know how much I am allowed to share.
from jpype import *
import jpype.imports
try:
jpype.addClassPath("jars/sdk.jar") #the relative path to the jar file
jpype.startJVM(convertStrings=False)
java.lang.System.out.println(jpype.getClassPath()) #printing the classpath to check, the path is correctly pointing to the sdk.jar file
java.lang.System.out.println("Hello world") #just to check if jpype is installed correctly, works
jpype.imports.registerDomain("a")
from a.b.c.d.e.f.g.h import SomeClass #fails here
except OSError as err:
print(err) # ToDo: Remove print when done
pass
The error I am getting is that the module a.b.c.d.e.f.g.h.SomeClass could not be found. I have tried different ways to give the path (absolute path, relative path, place the jar in different places in the project and outside of it), but that doesn't seem to be the problem, as the path printed is the correct absolute path to the jar file.
Also, the jar is used in other (Java) projects and it works. It is created using maven package (using IntelliJ, if it is relevant, and the same Java version as the one used by the JPype JVM). In the Java projects, the import would be:
import a.b.c.d.e.f.g.h.SomeClass;
I have copied this and just transformed the syntax into Python.
I have also tried to create the class with JObject (which I probably didn't do right anyway) and also tried the older syntax (to my understanding) with JPackage. For the JPackage way, I am getting the exception that the package a.b.c.d.e.f.g.h.SomeClass.someMethod is not Callable, which to my understanding is an equivalent exception to the one I'm getting using jpype imports. I have already gone through all the questions I could find here with similar problems, but none of those solutions have helped me.
Can anyone suggest some possible solution? Or can anyone see what I'm doing wrong? Suggestions of other possibilities to replace JPype are also welcomed. If there is any clarification needed, I will edit the question.

The only thing that seems likely if the jar is on the classpath and failed to import would be for there to be some missing dependency. You have two other ways to try loading the class which may provide additional diagnostics.
jpype.JClass("a.b.c.d.e.f.g.h.SomeClass")
and
jpype.JClass("java.lang.Class").forName("a.b.c.d.e.f.g.h.SomeClass")
The first is manually loading a class by full class specification. It is mechanically what is happening under the import. The second is calling for Java to load the class (bypassing all of JPype). It returns a java.lang.Class which can be passed to JClass to make a wrapper.
Common failures include missing a jar or native library, attempting to start JPype from within a module and having the wrong relative path, error in initialization of the class due to missing resource. JPype is just calling JNI calls, so if everything is fine on Java end it should work. Given that you checked the java.class.path System variable, it has to be something to do with class resources.
The JPype user manual has an alternatives section if you would like to try to find another package. Most of the alternatives with the exception of PyJnius appear to be unmaintained.

Why isn't my ORDS servlet executing, even though I've followed the existing guidelines?

I'm presently writing an ORDS plugin which is intended to filter certain requests. I'm not quite about to get the filtering working, so I decided to follow Oracle's provided instructions for their Plugin API.
I've configured much of the build with a Gradle task which automatically:
Downloads the WAR
Adds the plugin JAR (also previously built with Gradle) to ORDS
Ensures that the configdir is set appropriately
Effectively, this is the automated equivalent to me running:
# Assuming the JAR is cURL'd in from somewhere...
java -jar ords.war plugin build/myPlugin.jar
java -jar ords.war configdir /home/makoto/ords-configuration
...and I deploy this to my local IntelliJ instance.
Here is what my servlet looks like. It's pretty basic.
import oracle.dbtools.plugin.api.di.annotations.Provides;
import oracle.dbtools.plugin.api.http.annotations.Dispatches;
import oracle.dbtools.plugin.api.http.annotations.PathTemplate;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
#Provides
#Dispatches(#PathTemplate(("/plugin/servlet/")))
public class TestServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.getWriter().println("this worked?!");
}
}
I'm led to believe by the documentation that I should be able to access it at http://localhost:8080/ords/my_schema/plugin/servlet/, but that doesn't seem to be the case. I'm instead greeted with a 404:
DispatcherNotFoundException [statusCode=404, reasons=[]]
at oracle.dbtools.http.entrypoint.Dispatcher.choose(Dispatcher.java:87)
at oracle.dbtools.http.entrypoint.Dispatcher.dispatch(Dispatcher.java:98)
at oracle.dbtools.http.entrypoint.EntryPoint$FilteredServlet.service(EntryPoint.java:240)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:73)
at oracle.dbtools.url.mapping.RequestMapperImpl.doFilter(RequestMapperImpl.java:125)
at oracle.dbtools.url.mapping.URLMappingBase.doFilter(URLMappingBase.java:103)
at oracle.dbtools.url.mapping.filter.URLMappingFilter.doFilter(URLMappingFilter.java:148)
at oracle.dbtools.http.filters.HttpFilter.doFilter(HttpFilter.java:47)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:64)
at oracle.dbtools.http.cors.CORSResponseFilter.doFilter(CORSResponseFilter.java:83)
at oracle.dbtools.http.filters.HttpResponseFilter.doFilter(HttpResponseFilter.java:45)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:64)
at oracle.dbtools.http.errors.ErrorPageFilter.doFilter(ErrorPageFilter.java:94)
at oracle.dbtools.http.filters.HttpFilter.doFilter(HttpFilter.java:47)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:64)
at oracle.dbtools.http.auth.ForceAuthFilter.doFilter(ForceAuthFilter.java:44)
at oracle.dbtools.http.filters.HttpFilter.doFilter(HttpFilter.java:47)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:64)
at oracle.dbtools.http.filters.Filters.filter(Filters.java:47)
at oracle.dbtools.http.entrypoint.EntryPoint.service(EntryPoint.java:82)
at oracle.dbtools.http.entrypoint.EntryPointServlet.service(EntryPointServlet.java:49)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at oracle.dbtools.rt.web.HttpEndpointBase.dispatchableServices(HttpEndpointBase.java:116)
at oracle.dbtools.rt.web.HttpEndpointBase.service(HttpEndpointBase.java:81)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
-- snip --
What am I missing? I'm unclear as to what should be a very basic servlet - which is virtually analogous to the "Hello World!" example they have provided - is simply not registering appropriately.
Note:
The schema is enabled for ORDS.
This error happens with both containers I've used; Glassfish and Tomcat.
I am not using APEX, which seems to be a common add-on for this product. I'm intending to use ORDS as a RESTful provider for my data.
The trailing slash in the #Dispatches path doesn't seem to have an effect; if it's removed or if it's present the issue remains.
I am looking for authoritative answers or insights as to what could be going on here. Guesses and shots in the dark do me no good, as I've been tinkering with this myself, and there's a very good chance that our tinkering paths would have overlapped.
As loath as I am to add pictures to any question, BalusC suggested that I inspect the contents of the JAR to ensure that there's a specific providers file contained within.
From this screenshot, there appears to be two...
...and their contents are the same...
com.foo.bar.baz.bing.servlet.TestServlet
oracle.dbtools.plugin.api.di.AnnotationsProvider
...but when I go to extract the JAR and inspect the file, it only contains the AnnotationsProvider line.
oracle.dbtools.plugin.api.di.AnnotationsProvider
But wait! It gets weirder!
When I mount the JAR to extract individual files, I see lots of duplicates:
...which leads me to believe that, somehow, the older file is overwriting the newer file.

I've figured the issue out. BalusC's suggestion pointed me in the right direction.
ORDS expects providers to be registered through a file called META-INF/oracle.dbtools.plugin.api.di.providers. In this file is a list of classes described by their fully-qualified name which have been annotated with #Provides. Any class which doesn't appear in there will not be picked up by ORDS.
What I was running into, as highlighted by my question, was duplicate file names present within the JAR. If I observed it through Neovim, I'd see my FQN classes in one file, and none in another. If I observed it through Nautilus/File Extractor, I'd only see the file with none of my FQN classes.
The duplicate file issue turned out to be the smoking gun. In order for me to get this to work, I had to remove duplicates from my built JAR. In Gradle, the way to accomplish this is as thus:
jar {
duplicatesStrategy = DuplicatesStrategy.EXCLUDE
}
Now, only the correct *providers file shows up, and my servlets are able to be hit within ORDS.
I will point out that this was a surprise; I didn't anticipate any kind of duplicate files to be packaged within the JAR, nor did ORDS documentation potentially warn about this issue. I see this as a fair beacon to other devs to be mindful of this happening.

I see in source code of the demo plugin JAR that it registers itself with a SPI. That's the way how the ORDS core in WAR finds it. The provided Ant task in ORDS example folder takes care of generating the necessary SPI files while creating the JAR. You mentioned that you used a Gradle task for this, so I gather that you wrote it yourself.
In order to verify if your Gradle job generated the correct JAR too, extract the Gradle-produced plugin JAR file and inspect if there's a /META-INF/oracle.dbtools.plugin.api.di.providers file with the sole content the FQN of your TestServlet. If not, then it definitely won't be discovered by ORDS core in WAR.
You could confirm whether your plugin servlet's source code is correct by replacing the PluginDemo servlet source code with your own servlet contents and then building the JAR using the provided Ant task as instructed in the tutorial. If that works, then it's definitely the Gradle task which needs to be fixed and not your plugin servlet. However, a detailed answer on that can't be given as this information is missing in the question. But it should at least push you in the right direction in order to nail down the issue.

Java disutil CoordinateConversions import problems

I'm writing a Java class that will be used to send PDUs across a network- to do this, I am following the tutorial at: Tutorial
In the example, the line:
double lla[] = CoordinateConversions.xyzToLatLonDegrees(c);
appears towards the end of the class, and I see that CoordinateConversions has been imported with the line:
import edu.nps.moves.disutil.CoordinateConversions;
I have tried using the xyzToLatLonDegrees(); method in the class that I am writing- calling it in the same way as is done in the example. However, for some reason, I get a compile error that says:
CoordinateConversions cannot be resolved
on the line where I'm trying to use it, and
The import edu.nps.moves.disutil.CoordinateConversions cannot be resolved
on the line where I am importing it.
Does anyone know why this is, and how I can fix the import, so that I can use the xyzToLatLonDegrees() method?

You need to have the CoordinateConversions class on your classpath. Either by obtaining the source and dropping it into your project (possibly adjusting package names, and only if the license allows), or by finding a JAR containing that class and adding it to your build path in your IDE.
You probably need to download the Java files from here.

NoClassDefFoundError when code moved from R2007a to R2013a

I am working on moving code from R2007a to R2013a. I am getting a java.lang.NoClassDefFoundError during my run in R2013a which does not appear in R2007a. It occurs when I call.
feval('get',fname,jevent);
Where fname is a product.ProxyField object for an Object Filter and jevent is a product.format.java.internal.JavaEvent.
The class is in a jar file on the path and is being accessed by another class in the same jar file. The stack trace does not leave the realm of the product if that helps.
I do not have access to the original code for the jar file. I do have access to code derived from that original code and both classes are in the same package. I'm guessing this has something to do with differences in the java version but I'm not sure what to do since I don't have the original code to recompile.
Unfortunately I can't provide actual source or full detail but a google search only yielded results for MATLAB startup issues. Any thoughts?

Seems like the difference between R2007a and R2013a is that the first uses 1.5 jre and second uses 1.6 jre. It would be easier to help you if you provided the stack trace showing the exception. Sometimes classes get moved around in between jvm versions, so having the actual missing classes would help in determining if the missing class is a class that was just moved around to a different package. You could take the missing class, google it adding the same exception message as you put above and seeing who else ran into similar issues.