I am trying to create and use a set of Java classes from WSDL using Apache Axis 2. I’ve successfully generated the class files using the approach described here:
http://www.gerd-riesselmann.net/scala/creating-java-classes-wsdl-file-using-apache-axis-2
I have copied the generated class files into my eclipse development environment. I have obtained all the necessary jar files and I have added them to my environment.
A single (source) problem remains that I don’t understand. The code section looks like this:
...
public org.tempuri.PreprocessingIncidentImportServiceStub.ImportResponse
import (org.tempuri.PreprocessingIncidentImportServiceStub.Import import0)
throws java.rmi.RemoteException
{
org.apache.axis2.context.MessageContext _messageContext = null;
...
Eclipse is reporting: Syntax error on token "import", expected identifier.
I don't understand the function definition that includes the "import" statement, and I am wondering if there's some eclipse setting that I must use to resolve this problem.
Thanks in advance for any help.
It seems that the method is named import. Import is a reserved word in Java so you can't name a method with it.
Assume that you have imported the classes and doesn't need to use the full qualified name of them. This is what you have:
public ImportResponse import (Import import0) throws RemoteException{
//...
}
Related
I'm currently trying to fiddle with images, specifically convert images from JPEG, WEBP, and BMP forms to PNG forms and my method uses the javax.imageio.ImageIO class. When I tried importing it, Eclipse yelled that the package that the type was not accessible. I thought that was weird and went digging through StackOverflow on my own and found multiple answers saying I should remove and re-add the JRE. This didn't work, somewhat unsurprisingly, but while looking through my build path I noticed that the JRE was missing the entire javax package. Is there a reason this could be? Is there a fix?
The exact error reads The type javax.imageio.ImageIO is not accessible and the suggested edits ask me if I want to make class ImageIO in package javax.imageio.
I am using the latest build of Eclipse. My JDK is java-16-openjdk-amd64. I am running Ubuntu 20.04. I built this app from the ground up, so I am not using Maven (unless Eclipse uses Maven by default).
I tried compiling a basic class in my command line and it worked for some reason, despite not working in Eclipse.
I would rather not revert my JDK to an older version if I don't have to.
It turns out I was being just being an idiot. It turns out I had actually made this with a module without realizing it. All it took for me was to get rid of the module file.
You do not call "new" on a static class
To make an instance non static of it if it ever does have such a type available from one of its static methods you cast it to that type.
However, with the javax.imageio.ImageIO you make other classes from its methods.
import java.awt.image.BufferedImage;
import java.io.*;
try{ // wrap in FileNotFoundException IOException
File input = new File("/somewhere/over/the/rainbow/cementplant.jpg");
//static classes are called directly with a method
BufferedImage bfi = (BufferedImage)javax.imageio.ImageIO.read(input);
I have downloaded a voice/text API for java from
http://voce.sourceforge.net/
However being semi new to java I am unsure how to use all these jar files in my code, have tried several things like import voce, import java.voce, package (my folder name with the voce jar inside).
However I am getting no luck.
Code I am trying is
import java.voce;
public class SpeechInterface
{
public static void main(String[] args){
voce.SpeechInterface.synthesize("hello world");
}
}
Error I get is that it cant find voce(since I am obviously doing this wrong). Have looked through stackoverflow but was unable to find a question that answers this. I imagine there is one like this already but I can not find it. Closest I could find was the importing voce to C, but that wasn't to helpful.
The jar file is in same directory as the java file.
try using
import voce.*
If you look at http://voce.sourceforge.net/api/java/_speech_interface_8java-source.html
It mentions the package as (package voce).
Here under the Tab no 10. You can find how to add a Jar file to Dr.Java IDE,
Then as Kakarot Mention , you should to write
import.voce.*;
if you need all the classes of package voce,
or write
import.voce.classname
to import a specific class.
I have a java project that is using two imported jars with the same class (com.sun.mail.imap.IMAPFolder). Is there a way to explicitly say which jar to use when importing the class? Using:
import com.sun.mail.imap.IMAPFolder;
would seem to use the class in order of build path order but this does not seem to be the case for some reason causing
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.NoSuchMethodError: com.sun.mail.imap.IMAPFolder.idle()V
at com.woodbury.GCM.HelperGmailMonitor.doEmail(HelperGmailMonitor.java:104)
at com.woodbury.GCM.Launch.listen(Launch.java:16)
at com.woodbury.GCM.Launch.main(Launch.java:10)
... 5 more
at runtime. I am building the project in eclipse.
When a class is loaded, the first implementation that matches the requested fully qualified name that is visible to the relevant ClassLoader is what gets returned. Any other implementations with the same fully qualified name are effectively hidden to that ClassLoader.
What this means in a standard Java SE application is that the first code base (e.g. a jar) listed on the classpath with the required class, provides it, and all other code bases' implementations of the same fully qualified class are hidden.
Example:
Assume that A.jar contains the compiled class
package com.stackoverflow.example;
public class Hello {
public static String getGreeting(){
return "Hello, A!"
}
}
Assume that B.jar contains the compiled class
package com.stackoverflow.example
public class Hello {
public static String getGreeting(){
return "Hello, B!"
}
}
Note that in both of the above classes have the same fully qualified name.
Assume main class is
import com.stackoverflow.example.Hello;
public class ExampleMain {
public static void main(String[] args){
System.out.println(Hello.getGreeting());
}
}
If I were to invoke my program with
java -cp A.jar:B.jar ExampleMain
the output is: Hello, A!
If I reverse the classpath like so
java -cp B.jar:A.jar ExampleMain
the output is: Hello, B!
You cannot do what you ask just in your Java source. Java was not designed for that.
This is a bad situation which can only be handled reliably with custom class loaders, each providing one of the jars you need. Since you are asking this question in the first place this is probably not the way you should go yet since that opens up a LOT of new time consuming problems.
I would strongly suggest you find out why you have two different versions of the same jar in your classpath and rework your program so you only need one version.
Yes, there is a way to fix the issue. In my scenario, I have two classes with same name and same path and eclipse always imports the wrong one. What I have done is changing the jar order in the build path and eclipse will pick the first one in the build path.
If you are using an IDE, you can set the order of exporting the files to the class loader.
I work on eclipse and I use maven. When I install the project using maven, it produced many extra jars (which i hadnt defined in my dependencies) and there was a file org.w3c.dom.Element which was present in 2 jar files and 3rd instance of the same file was also in JRE7.
In order to make sure the correct file is picked up, all I had to do was to go to Java Build Path -> Order and Export. Select the Jar file I wanted the classloader to give more preference and move it up with the button "Up".
This is how it looks.
Please note that this image is for eclipse. But for other IDEs there would definitely be a similar way to work this out.
1) In general: Yes you can have the same class in different .jar files: you just disambiguate them with a fully qualified package name. The "Date" class (present in java.util and java.sql) is a good example.
2) If you have two DIFFERENT .jar files that have the SAME fully qualified package names ... chances are, you've got a conflict. Even if you can hack around the InvocationTargetException by playing with the class loader, you might still encounter other problems. In this case, it sounds like maybe your two .jar files have two different implementations of the JavaMail API. I don't know.
3) The safest bet is to satisfy all your program's references WITHOUT risking a conflict. I believe if you took took the "official" .jar's from Oracle's JavaMail web page, you can do this:
https://java.net/projects/javamail/pages/Home
'Hope that helps!
I am trying to make some changes to a legacy code of a plugin which was written using Java version 4. I am trying to extend a class from an imported package.
import org.eclipse.wst.xml.core.internal.document.XMLModelContext;
public class XMLModelContextForPma extends XMLModelContext
{
}
I'm quite new to plugin development. I couldn't figure out why the compiler shows
The type org.eclipse.wst.xml.core.internal.document.XMLModelContext is not visible error. Also, most of the codes in classes of this particular package are using .internal. packages which are giving Discouraged access warnings. I'm googled here and there and found it's because of non-standard/API classes.
But this is quite strange. I have the jar files in the build path but not sure what is wrong here.
I'm developing in Eclipse Juno, Mac OS X, Java 6
It looks like the class XMLModelContext is private or protected and in a different package.
If a class is declared as protected, you can only use it in other classes within the same package or any of it's sub packages.
Add that jar(org.eclipse.wst.xml.core.internal.document.XMLModelContext containing jar) to your project file path.
I am using a 3rd party annotation processor for generating meta-data code (.java files) from the annotated classes in my project.
I have successfully configured the processor through Eclipse (Properties -> Java Compiler -> Annotation Processing) and the code generation works fine (code is automatically created and generated). Also, Eclipse successfully auto-completes the generated classes and their fields, without any errors. Let's say that I have a class "some.package.Foo" and that the generated meta-data class is "some.package.Foo_". By the help of auto-completion, I can get the following code in the Eclipse editor, without any errors:
import some.package.Foo_;
...
public class Test {
void test() {
Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
However, as soon as I actually build the project (or just save the file since Build automatically is enabled), I get the error which tells that "some.package.Foo_" cannot be resolved.
It seems like Eclipse is generating and compiling the some.package.Foo_ at the same time, or more likely.
I found two temporary solutions (which are practically hindering the use of the annotation processor in the first place):
Before each build of that generated classes, right click on every generated file go to Properties and uncheck the "Derived" tick. After that, I do the cleanup of the project and the imports are fine - there are no more errors. However, if I do the cleanup one more time, the errors again show up, because the generation of the files causes the "Derived" tick to be checked again (automatically). So this is really annoying and time-consuming.
I also uncheck the "Derived" tick
from all those files, and this time
I uncheck the "Derived" tick from
the source folder and packages which
contain those files. Then I disable
the annotation processor, and then
do the cleanup. There are no more
import errors, even if I do another
cleanup, but there is no benefit of
using the annotation processor,
because if I was to change something
which would update the model, I need
to turn the annotation processor
back on, and repeat this tedious
procedure to turn it off, after it
has generated the new version of
those files.
Is this a bug in Eclipse? If yes, is there a better workaround or quick-fix than the two I have stated above? If not, what should I try to solve the problem?
I also tried rearranging the order of the libraries on the build path and it doesn't help.
I assume that you are generating sources in the last processor round. This is not recommended way and leads exactly to the problem that you had.
Explanation is here: http://code.google.com/p/acris/wiki/CodeGenerationPlatform_Pitfall_Rounds
So the my advise is to generate sources in regular processing rounds and final round should be used just for notification that processing is over or something like that.
Hopefully this helps you.
I have a similar problem, and the only thing I've found is that it's the imports specifically that don't work, but the references in the class itself do work. The workaround I've used is to use the FQCN in all cases where the generated class is needed (except when the generated class is in the same package, since then the import is obviously not needed).
So to use your example, I'd do:
public class Test {
void test() {
some.package.Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
My only guess then is that the eclipse compiler is processing the imports before doing the annotation processing, which imho must be a bug in eclipse.
I know this question is over a year old, so I'd be interested to know if you've found any other way to fix it.
We were experiencing a similar problem and apparently just solved it, so thought of sharing it at SO, in case it helps someone.
We are using:
Eclipse Indigo (Build id: 20120216-1857)
m2e Connector for maven
openJPA for static metamodel class generation
Our problem:
Say, we have a package named com.abc.xyz and an entity class in there named OurEntity. When we build the projects (JPA, EJB, EAR etc. all together with an mvn clean at the beginning) the metamodel classes get generated. And also get appropriately packaged within the PU jar. But when we try to import the generated metamodel class com.abc.xyz.OurEntity_, Eclipse cannot resolve it. OP apparently got past this point:-). Maven build failed, saying it could not resolve that class. Not much help from google except for a few bug reports such as this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=350378
That bug report said importing the whole package as opposed to the single class helped. So, tried that, but with no benefit. It also said (and so did David Heitzman) that using the fully qualified class name worked for them. That did not work either.
The solution:
Added the PU jar to Eclipse build path for the project that needed to use the metamodel classes. All of a sudden all the red underlines went away (not a surprise). But the fear was there might be two PUs in the same ear. But maven automagically took care of that.
As this rather old question got some attention without pointing to the very probable eclipse bug the OP was specifically asking for, I'd like to complement the above answers with a pointer to the eclipse bug tracker:
Cannot resolve import for generated class IF processing annotations with parameters referencing constants
The workarounds include
doing a wildcard import of the package defining the generated classes (i.e. import some.package.*;)
using the fully qualified name of your generated class, i.e. referring to some.package.Foo in your code and not using an import
switch to a newer Eclipse. This specific eclipse bug is resolved with Eclipse version 4.4 (aka Luna).