|
From: <php...@li...> - 2008-12-12 00:06:49
|
Hello, I've got this error I'd like some help with. I'm using Apache POI 3.5 to read XLS and XLSX files, but trying to do: $workbook = new org_apache_poi_xssf_usermodel_XSSFWorkbook(); fails with: java.lang.Exception: CreateInstance failed: new org.apache.poi.xssf.usermodel.XSSFWorkbook. Cause: java.lang.ClassNotFoundException: Unresolved external reference: java.lang.NoClassDefFoundError: Could not initialize class org.openxmlformats.schemas.spreadsheetml.x2006.main.CTWorkbook. -- Unable to call constructor, see the README section "Java platform issues" for details. However, in the same page, when I call: $wb = new org_openxmlformats_schemas_spreadsheetml_x2006_main_CTWorkbook(); the code doesn't complain. Also, a pure Java application that instantiates XSSFWorkbook and manipulates it works fine. So my question is: how to debug such problems? Where to start? I downloaded DependencyFinder (http://depfind.sourceforge.net/) to see if the referenced jars use other packages that are not present, but I didn't find any. TIA, Karim |
|
From: <php...@li...> - 2008-12-12 17:19:06
|
Hi,
please see our FAQ "Why do I get a NoClassDefFoundError?"
> the code doesn't complain. Also, a pure Java
> application that
> instantiates XSSFWorkbook and manipulates it works fine.
Whether or not calls are routed through a TCP socket and the java reflection machinery doesn't make a difference; so if your application works standalone, it will work as well when the same sequence is called via the bridge protocol from a remote PHP/Scheme/Python application.
Regards,
Jost Boekemeier
|
|
From: <php...@li...> - 2008-12-12 22:10:20
|
Thanks for your reply. After re-reading the FAQ thoroughly, I made several experiments to see the bridge's reaction to placing the jars in different places. What I found is this: I had given a *relative* path for each jar to java_autoload. It loaded them successfully, and I was able to *explicitly* instantiate classes from all those autoloaded jars. However, if a Java class A tried to instantiate a class B located in another jar, it ran the risk of not finding the appropriate jar (even though, again, PHP was able to instantiate B). What I mean by "risk" is that loading only sometimes failed. When I specified the *absolute* paths for the jars, the problem went away. I would humbly suggest to document this behaviour in the FAQ, or to fix the bridge such that the VM's class loader behaves just like java_require. Thanks, K. |
|
From: <php...@li...> - 2008-12-14 14:52:30
|
Hi,
> instantiate a class B located in another jar, it ran the
> risk of not finding the appropriate (class),[...] even though,
> PHP was able to instantiate B)
I think this is pretty obvious, as it follows from the FAQ statement "all classes and their dependencies must be loaded by one, and ony one, class loader"
If you have any suggestions how we could improve our documentation, please let us know.
> fix the bridge such that the VM's class loader behaves java_require.
You seem to think that this is a PHP/Java Bridge issue, but it isn't. Kay's dynamic class loader simply passes on what Java has to offer.
Regards,
Jost Boekemeier
|
|
From: <php...@li...> - 2008-12-14 18:33:41
|
Hi, How does the statement "all classes and their dependencies must be loaded by one, and only one, class loader", relate to the observation that: 1. required jar files for Java classes A and B were included in java_require 2. PHP script was able to instantiate class B 3. class A was not able to instantiate that same class B? 4. this behaviour occurred because of supplying relative paths to java_require Furthermore, doesn't that observation indicate an inconsistency in class loading mechanism? Apologies for my lack of understanding, Karim |
|
From: <php...@li...> - 2008-12-14 19:32:49
|
Hi,
> 1. required jar files for Java classes A and B were
> included in java_require
> 2. PHP script was able to instantiate class B
> 3. class A was not able to instantiate that same class B?
Class B came from another class loader which has no relationship to the loader for (A,B), most likely the bootstrap loader. Which means that you have violated the module contract.
> 4. this behaviour occurred because of supplying relative
> paths to java_require
Whether or not a library has an absolute or relative path is irrelevant.
> Furthermore, doesn't that observation indicate an
> inconsistency in class loading mechanism?
Yes, definitely. This part of the Java platform is broken by design.
Compare it with .NET or with SML/NJ. -- There was a proposal for a real module system based on generics, but this needs real generics within the JVM, something that Java doesn't support either (current Java 1.5 generics are syntactic shugar, for the compiler and for marketing).
However, this doesn't have anything to do with the PHP/Java Bridge.
Regards,
Jost Boekemeier
|
|
From: <php...@li...> - 2008-12-14 21:15:40
|
Thanks for your explanation. The Java class loader is a tricky beast. On Sun, Dec 14, 2008 at 11:32 AM, <php...@li...> wrote: > Hi, > >> 1. required jar files for Java classes A and B were >> included in java_require >> 2. PHP script was able to instantiate class B >> 3. class A was not able to instantiate that same class B? > > Class B came from another class loader which has no relationship to the loader for (A,B), most likely the bootstrap loader. Which means that you have violated the module contract. > > >> 4. this behaviour occurred because of supplying relative >> paths to java_require > > Whether or not a library has an absolute or relative path is irrelevant. > > >> Furthermore, doesn't that observation indicate an >> inconsistency in class loading mechanism? > > Yes, definitely. This part of the Java platform is broken by design. > > Compare it with .NET or with SML/NJ. -- There was a proposal for a real module system based on generics, but this needs real generics within the JVM, something that Java doesn't support either (current Java 1.5 generics are syntactic shugar, for the compiler and for marketing). > > However, this doesn't have anything to do with the PHP/Java Bridge. > > > Regards, > Jost Boekemeier > > > > > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > php-java-bridge-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users > |