php-java-bridge-users Mailing List for PHP/Java Bridge

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
>

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




      

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

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