Hi, I have a third party JAR file which i need to use in my program. I have the .jar file path in my CLASSPATH and my program which uses a class which is inside this jar. If my program doesnot have any package declaration then it compiles properly. If I introduce package statement in my program then it doesnot recognise the class which is inside the .jar. The third party class doesnot belong to any package i.e. the class has default scope. I refered one thread in Sun Forum having same problem. http://forum.java.sun.com/thread.jsp?forum=31&thread=385595 Is it impossible for me to use this class inside the jar without packaging my program ? Thanks for the time.
<b>L G Goundalkar</b><br /> <a href="mailto:lggoundalkar@yahoo.com" rel="nofollow">lggoundalkar@yahoo.com</a> <br />Sun Certified Programmer for Java 2 Platform.<br />Sun Certified Web Component Developer for J2EE.
Ajay Singhal
Ranch Hand
Joined: Jan 10, 2001
Posts: 37
posted
0
Hi, can you specify the put the classpath and the package structure in your message. write down the steps so that the problem can be recognised...it must be some basic mistake. Ajay
L Goundalkar
Ranch Hand
Joined: Jul 05, 2001
Posts: 395
posted
0
Well.. I have ujlicense.jar which contains class for validating license, i.e. UJLicense. This is a third party tool. I have made entry in CLASSPATH i.e. CLASSPATH=c:\myjars\ujlicense.jar;. My program validates the licesne using UJLicense instance. When I compile my class it doesn't recognise the UJLicense class if I use package statement in my program. If I remove he package it works fine. i.e. Gives Compilation error
This one works fine..
Hope this gives clear picture of the problem.
Maulin Vasavada
Ranch Hand
Joined: Nov 04, 2001
Posts: 1865
posted
0
Hi L G Goundalkar The problem you are facing is due to the Java 1.4 new requirment which forces to have packages all the way if you have packages in one place. So, a packaged class can't refer to the "unpackaged" class even if it is there in the Classpath. So, when you put a package in your code it can't find the class in the jar file but when you remove the package from your code it works Now, I'm thinking of a possible solution... Regards Maulin
Humm.. what shall I import when my third party API is not packaged !!! does import .*; works ?? Cheers.
Brian Pipa
Ranch Hand
Joined: Sep 29, 2003
Posts: 299
posted
0
Oops - disregard my post - I misread and didn't realize the 3rd party API had no package. brian
Maulin Vasavada
Ranch Hand
Joined: Nov 04, 2001
Posts: 1865
posted
0
Hi L Goundalkar I guess we are in trouble here. I tried with some options but won't work that way I am not feeling comfortable with this new constraint Java has imposed ( I faced it myself earlier when I asked "why so" and didn't seem to get lot of responses here in one of the posts ). This should probably filed as a request to revoke this constraint. I agree that we should have packages always BUT language shouldn't enforce this. Particularly when there are thousands of applications already developed using older design when the constraint was not there. It becomes extremely annoying to work with third party products where they don't have packages and we get stuck "just because Java came up with a new constraint".... Moderators, any opinions on this? Regards Maulin
Maulin Vasavada
Ranch Hand
Joined: Nov 04, 2001
Posts: 1865
posted
0
One alternative would be to write our custom classloader that would solve our problem for "runtime" but if we are not able to compile then I am not sure where to go... Regards Maulin
L Goundalkar
Ranch Hand
Joined: Jul 05, 2001
Posts: 395
posted
0
I totally agree with you Maulin. Well just to use a thrid party API we need not end up creating our own classloader. There should have been some way where i could over rule this constraint. Hope some moderators will throw some light on this. Cheers.
Maulin Vasavada
Ranch Hand
Joined: Nov 04, 2001
Posts: 1865
posted
0
Help us!!!
Ernest Friedman-Hill
author and iconoclast
Marshal
Believe it or not, your Bartenders are not omniscient, all-powerful beings. At least not all of use are Anyways, I've looked at this thread before, and I don't have anything useful to contribute. This is actually a tricky problem. There are two different solutions I can think of. Neither one is as nasty (or ineffective, actually) as writing your owbn ClassLoader. Note that Java has no problem loading such a class. It's only javac, the compiler, that is enforcing this.
One possiblity is to compile the class that accesses this unpackaged class with an older Java compiler. You could write a packaged "wrapper" class for the unpackaged class which just forwarded the method calls, compile it once with an old Java compiler, then put both classes into a jar file, and never touch the contents of that file again. This is not a bad solution, really.
Another one that's only slightly harder: use Class.forName() to load the class at runtime, then use reflection to call the method (i.e., use Class.getDeclaredMethods() to find the method you want to call, and use Method.invoke() to actually call it. Again, you could do this in a wrapper for the original class, so that the rest of the application could just call the methods of the wrapper.
Finally, you could complain, bitterly, to the vendor that's selling you this crappy code. JDK 1.4 has been out for a very, very long time now -- they have no excuse for not upgrading their APIs. Unless they're out of business, of course.