Thread: [Php-java-bridge-users] PLEASE name globally visible variables very unique!

My application always failed mysteriously the very moment I included the
Java-bridge (i.e. as soon as I added "
require_once('http://localhost:8080/JavaBridge/java/Java.inc');" to my
code, I didn't actually *use* anything from it, yet, just including it was
enough to break my application.

After some quite substantial investigation I had to learn, that the reason
was, that the Java.inc file uses a globally visible variable "$version"
(which in line 4) is set to the current php-version and then compared to
'5.1.2' to give a warning if this is executed on a lower php-version.

Apparently some other code that I am using also checks for such a variable.
It expects to find 1.0.0 but now found 5.2.3 (the PHP version I am using)
and then behaved completely differently, i.e. eventually did not work at
all, since it combined that variable into a filename and then did not find
a file required and failed.

To verify this, I made myself a copy of Java.inc where I renamed this
variable and now everything works as expected.

So, dear PHP/JavaBridge developers:
if you use (and then leave around) such globally visible variables, then
PLEASE make their names VERY unique. The name "version" is obviously too
likely to appear in other's code as well and then can have very strange
side-effects!

I even suggest to NOT use any variable here, but to write this snippet as
follows:
      ...
  if ((version_compare("5.1.2", phpversion(), ">"))) {
      $msg = '<br><strong>PHP '.phpversion().' too old.</strong><br>\nFor
PHP versions < 5.1.4 install the java.so or php_java.dll from the
php-java-bridge-legacy download.<br>\nOr set the path to the PHP
executable, see php_exec in the WEB-INF/web.xml';
      die($msg);
  }
     ...

In the (hopefully rare) case where this test fails, it doesn't really hurt
to call the method twice (since the code is terminated anyway) and in the
good case this doesn't leave any traces.

Regards,
Michael

Hi,

> code, I didn't actually *use* anything from it, yet, just including it was
> enough to break my application.

how can a temporary variable, which is used only within the Java.inc block, break your
application?

 
> After some quite substantial investigation I had to learn, that the reason
> was, that the Java.inc file uses a globally visible variable "$version"

$version is a variable which is used only in the if() block. Since php currently doesn't support
name spaces, it is created in the global environment instead. Whether or not an included library
uses temporary bindings in the global environment should not affect a well-written application.

For version 4.2.3 we could turn the code block into a lambda() and immediately invoke it. This way
the bindings are created local to the anonymous function and do not pollute the global env.

> Apparently some other code that I am using also checks for such a variable.
> It expects to find 1.0.0 but now found 5.2.3 (the PHP version I am using)

Isn't it possible to keep your *global variables* in a separate map? BTW: I would prefix all
global variables with appname_ to avoid clashes with other libs. Temporary bindings don't need to
prefixed, though. 


> if you use (and then leave around) such globally visible variables, then
> PLEASE make their names VERY unique.

This means that we have to prefix all *temporary* variables with java_. I don't think this is a
good idea. 

However, we can and probably should turn global code blocks into anonymous functions and invoke
them immediately.


> I even suggest to NOT use any variable here, but to write this snippet as
> follows:
>       ...
>   if ((version_compare("5.1.2", phpversion(), ">"))) {
>       $msg = '<br><strong>PHP '.phpversion().' too old.</strong><br>\nFor

How does this help? The temp var $msg is also created in the global environment.


Regards,
Jost Boekemeier



       __________________________________ 
Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever

Hi Jost,=20

> -----Original Message-----
> From: php...@li...=20
> [mailto:php...@li...]=20
> On Behalf Of php...@li...
> Sent: Montag, 10. September 2007 11:32
> To: php...@li...
> Subject: Re: [Php-java-bridge-users] PLEASE name globally=20
> visible variablesvery unique!
>=20
> ...
> how can a temporary variable, which is used only within the=20
> Java.inc block, break your application?

OK - maybe "global" was the wrong term here. It's not really "global"
in the PHP sense. Apologies!
But it is "global" in the sense, that obviously the code, that I am
using (a widget library for which I was creating additional widgets
that then get dynamically loaded) creates an environment into which
that widget code gets dynamically loaded and embedded and in that
environment there obviously already exists a variable "$version".

> ...
> $version is a variable which is used only in the if() block.=20
> Since php currently doesn't support name spaces, it is=20
> created in the global environment instead. Whether or not an=20
> included library uses temporary bindings in the global=20
> environment should not affect a well-written application.

If there already exists a variable "$version" OUTSIDE (i.e. before)
the if-block, then obviously it takes that variable (and does not
create and use a new local var) and so overwrites its value, i.e. that
statement has an outside noticable effect.

> This means that we have to prefix all *temporary* variables=20
> with java_. I don't think this is a good idea.=20

Well - if you want to similar effect in other environments, then I
guess this would be needed. However, I just checked again, it seems
that $version was actually the only var that is used in that way.
Everything else seems to be used inside functions or classes and
should thus not harm. And all others var and constants that I found
during my quick glance ($JAVA_BASE, JAVA_HOST, JAVA_SERVLET,
JAVA_LOG_LEVEL, etc.) are already named such, that they are rather
unlikely to clash (and if they do, the names already suggests where to
look...). I hope I didn't miss any, though.
=20
> > I even suggest to NOT use any variable here, but to write=20
> this snippet=20
> > as
> > follows:
> >       ...
> >   if ((version_compare("5.1.2", phpversion(), ">"))) {
> >       $msg =3D '<br><strong>PHP '.phpversion().' too=20
> old.</strong><br>\nFor
>=20
> How does this help? The temp var $msg is also created in the=20
> global environment.

Agreed - one could even compose the msg directly in the method call
thus avoiding the declarartion and use of $msg, but since that
variable is only used in the subsequent die(...) anyway, I did not
consider that an issue, while the use (and possible modification) of
"$version" obviously IS an issue and should be avoided.

Look, I didn't mean to cause a major headache here. I only reported a
problem that I banged into using the PHP/JavaBridge in my environment
and a IMHO really minor change, that allows to fix this and avoid
similar griefs for others in the future.=20

Michael

Hi Michael,


> > This means that we have to prefix all *temporary* variables 
> > with java_. I don't think this is a good idea. 
> 
> Well - if you want to similar effect in other environments, then I
> guess this would be needed. 

I don't think so. People shouldn't write unnatural code. I have never seen prefixes for temporary
variables such as:

  for($myLib_i=0; $myLib_i<100; $myLib_i++) {...}


> that $version was actually the only var that is used in that way.

Other libraries use similar code in their setup. I don't see a problem 
with this. I don't even understand the problem.

If you use the following code:

  $i=something;
  require_once("some_lib.php") ::= { ...  for($i=0; $i<100; $i++) ... }
  doSomethingWith($i);

then there's a bug in your code, I think. Your global variable "$i" should be named "$myApp_i",
not simply "$i".


Regards,
Jost Boekemeier



      Wissenswertes für Bastler und Hobby Handwerker. BE A BETTER HEIMWERKER! www.yahoo.de/clever

> -----Original Message-----
> From: php...@li...=20
> [mailto:php...@li...]=20
> On Behalf Of php...@li...
> Sent: Montag, 10. September 2007 19:43
> To: php...@li...
> Subject: Re: [Php-java-bridge-users] PLEASE name globally=20
> visiblevariablesvery unique!
>=20
> ...
> Other libraries use similar code in their setup. I don't see=20
> a problem=20
> with this. I don't even understand the problem.


Sigh! My last attempt before giving up hope:

I have code like that roughly looks as follows.
 ---------------
 ...
 $version =3D '1.0.0'; // this may also - say - be passed in as
parameter.
 ...
 require_once(<php-bridge's Java.inc>);
 ...
 <do somethings with the java-bridge>
 ...
 // followed my some other code, that expects to see the=20
 // variable value defined at the begin (or being passed in):
 ...
 read_file('foo_bar_'.$version.'.xyz'); // supposed to read
'foo_bar_1.0.0.xyz'
 ...
 ---------------

then this code would now suddenly search for 'foo_bar_5.2.3.xyz'
(which most likely will not exist and hence this method fails), since
the innocently looking require_once(...) has modified the $version
variable during the check for the current php-version.

Why is it so hard to understand, that I simply ask, NOT to use a
variable called "$version"? As we have seen this is a very likely
variable name, may thus already exist and its modification can lead to
unexpected results.=20

I guess your answer will now be: MY code should not use a variable
called "$version", but since this is code that sits in a third party
library that I do not want to modify (since I then would have to
repeat  that same modification in each new version) this is not an
option.

Hope I could make myself clear and if not I don't care any more...

Michael

Why not just include java.inc first?  Then, even if it does use variables they you've set, then you'll overwrite the value and it won't be an issue.  I can't see any reason why you couldn't do the include at the top of the page.  I always put it just after session_start();

--Nathan Shaskin
Compliance Publishing

php...@li... wrote: > -----Original Message-----
> From: php...@li... 
> [mailto:php...@li...] 
> On Behalf Of php...@li...
> Sent: Montag, 10. September 2007 19:43
> To: php...@li...
> Subject: Re: [Php-java-bridge-users] PLEASE name globally 
> visiblevariablesvery unique!
> 
> ...
> Other libraries use similar code in their setup. I don't see 
> a problem 
> with this. I don't even understand the problem.


Sigh! My last attempt before giving up hope:

I have code like that roughly looks as follows.
 ---------------
 ...
 $version = '1.0.0'; // this may also - say - be passed in as
parameter.
 ...
 require_once(
);
 ...
 
 ...
 // followed my some other code, that expects to see the 
 // variable value defined at the begin (or being passed in):
 ...
 read_file('foo_bar_'.$version.'.xyz'); // supposed to read
'foo_bar_1.0.0.xyz'
 ...
 ---------------

then this code would now suddenly search for 'foo_bar_5.2.3.xyz'
(which most likely will not exist and hence this method fails), since
the innocently looking require_once(...) has modified the $version
variable during the check for the current php-version.

Why is it so hard to understand, that I simply ask, NOT to use a
variable called "$version"? As we have seen this is a very likely
variable name, may thus already exist and its modification can lead to
unexpected results. 

I guess your answer will now be: MY code should not use a variable
called "$version", but since this is code that sits in a third party
library that I do not want to modify (since I then would have to
repeat  that same modification in each new version) this is not an
option.

Hope I could make myself clear and if not I don't care any more...

Michael


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
php-java-bridge-users mailing list
php...@li...
https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users



       
---------------------------------
Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center.

> -----Original Message-----
> From: php...@li... 
> [mailto:php...@li...] 
> On Behalf Of php...@li...
> Sent: Dienstag, 11. September 2007 00:04
> To: php...@li...
> Subject: Re: [Php-java-bridge-users] PLEASE name 
> globallyvisiblevariablesvery unique!
> 
> 
> Why not just include java.inc first?  Then, even if it does 
> use variables they you've set, then you'll overwrite the 
> value and it won't be an issue.  I can't see any reason why 
> you couldn't do the include at the top of the page.  I always 
> put it just after session_start();
> 
> --Nathan Shaskin
> Compliance Publishing

Because that part that declares $version is outside the code, that I
write, as is the code that later checks for it.

My code is dynamically, i.e. at runtime, embedded into this sequence.
The code that declares $version and the code that uses it are both
outside my control. I am essentially just providing the middle part
that returns some values (using the java-bridge). I agree, that this
is maybe not the best possible solution, but that's the way this
library, that I am using, works...

Michael

Hello!
  
  Why don't you simply put the code in a procedure and invoke it when needed?
  
  
  For example:
  
<?php
$version=3.14;

function func(){
 include("http://localhost:8080/JavaBridge/java/Java.inc");
} 
func();

$s = new java("java.lang.String", "hello");
echo $s; echo " "; echo $version;
?>
  should display hello 3.14.
  
  
  Peter
  

       
---------------------------------
Pinpoint customers who are looking for what you sell. 

>   Why don't you simply put the code in a procedure and invoke 
> it when needed?

Sure - it's a bit unusal though, to include stuff this way, but it
would work. 

Frankly, I don't quite understand why there is such unexpected and
strong reluctance to accept my proposed tiny, tiny modification. Just
change lines 5-7 from:
  ...
  $version = phpversion();
  if ((version_compare("5.1.2", $version(), ">"))) {
	$msg = '<br><strong>PHP '.$version.' too old.</strong>...
      ...
to:
  ...
  if ((version_compare("5.1.2", phpversion(), ">"))) {
	$msg = '<br><strong>PHP '.phpversion().' too old.</strong>...
  ...

and then there won't be any more such trouble (and also no special
"style" or wrapper necessary to include the bridge necessary). 

Take it or leave it...
Michael