# Einfaches Java Programm PHP5-fähig machen



## tF (9. Mai 2006)

Hallo zusammen,

ich habe eine mehr oder weniger fiese Frage ... Und zwar folgendes:


```
public class Main {	
	public static void main(String[] args) {
		String hello = PHP.exec("<?php echo(\"hello world\"); ?>");
		System.out.println(hello);		
	}		
}
```

Die Ausgabe dieses Programmes soll "hello world" sein.
Mit meiner jetzigen methode funktioniert das auch:

habe die php.exe und die php5ts.dll im selben verzeichnis liegen und starte über einen "Process" in Java die php.exe, übergebe dort per outputstream den code und lese das ergebnis per inputstream wieder ein.

allerdings frisst das mehr ressourcen als mir lieb ist ... ich möchte das gerne so lösen, dass java php als eine art modul einbindet ... so wie es der apache webserver macht ... der ruft nämlich auch nicht bei jeder php geschichte die php.exe auf.

im internet finde ich alles, nur nicht genau diese eine lösung ... im internet find ich nur möglichkeiten, in php java zu benutzen und php über tomcat in java zu benutzen ... dazu sei gesagt, dass ich das gerne OHNE tomcat lösen möchte.

hoffe hier sind einige helle köpfe im forum, die da evtl ein paar ideen haben ... obs möglichkeiten gibt, sone dll in java einzubauen oder ob es evtl andere dlls gibt, die da als schnittstelle dienen könnten ...

mir qualmt mitlerweile schon der schädel...  
grüße und thx für ideen

andi


----------



## AlArenal (10. Mai 2006)

Kurzum: Gibts nicht, geht auch nicht "mal so eben", ohne u.a. die INternas von PHP umzukrempeln. Es gibt mit BSF eine Möglichkeit diverse Sprachen an Java anzudocken, bzw. diese zu integrieren, aber dazu müssen beide Seiten einen Schritt aufeinander zugehen.

http://jakarta.apache.org/bsf/

Ich sehe auch nicht warum man versuchen sollte eine Sprache zu vergewaltigen, indem man von hinten durch die Brust ins Auge schießt. Du hast drei Möglichkeiten:

1. Du eignest dir genug Java Know-How an, um nicht auf PHP, o.ä. angewiesen zu sein.
2. Du benutzt eine der zahlreichen mit Java zusammenarbeitenden Skriptsprachen-Implementierungen (Groovy, JRuby, BeanShell, Jyhon, JPython, Tcl, JavaScript, ...), von denen Groovy in Java 7 wohl eh offiziell aufgenommen werden wird.
3. Du wartest bist du alt und runzlig bist, immer in der Hoffnung dass jemand mal PHP als Skript-Engine für Java umdengelt.


----------



## Leroy42 (10. Mai 2006)

AlArenal hat gesagt.:
			
		

> Groovy in Java 7 wohl eh offiziell aufgenommen werden wird.


 :shock: 
Verstehe ich das richtig? Java 1.6 gibt es noch gar nicht und da
wird schon an Java 1.7 gebastelt?

Ich werde auf absehbare Zeit nicht darum herum kommen, Utility-packages in
1.4 zu proggen, da es nicht absehbar ist wann unser Provider auf 1.5 umsteigt
und ich nicht gerne 2 Versionen parallel warten will. Geschweige davon, daß
ich, um nicht die gesamte InternetExcluder-Gemeinschaft auszuschließen, mich
bei Applets wohl ewig mit dem AWT herumschlagen muß.

Und _die_ sind schon bei 1.7  :autsch:


----------



## AlArenal (10. Mai 2006)

Das nennt man Planung.. was sollen denn die ganzen Strategen und Planer machen, wo die 6er Version schon in der Beta ist?

Bei MS wird man sich auch Gedanken drum machen, wie Vistas Nachfolger aussehen wird. D.h. nicht, dass schon alles iin Stein gemeißelt. geschweige den entwickelt ist...

Wenn BMW morgen ein neues Modell rausbringt, kannste auch einen drauf lassen, dass der Nachfolger schon heute in Planung ist.


----------



## byte (10. Mai 2006)

Leroy42 hat gesagt.:
			
		

> Ich werde auf absehbare Zeit nicht darum herum kommen, Utility-packages in
> 1.4 zu proggen, da es nicht absehbar ist wann unser Provider auf 1.5 umsteigt




Du armes Schwein. Mein Beileid...  :lol: 

Gerade 1.5 ist imo so ne Version, die man - einmal dran gewöhnt - nicht mehr missen will. Zumindest gehts mir so. :roll:


----------



## Leroy42 (10. Mai 2006)

Geht mir auch so!

Und wenn man aus der Programmierecke kommt, die bei Code wie

```
for (int i=0; i < stringVar.length(); ++i) ...
```
noch ein unangenehmes Kribbeln bekommt, dann _fühlt_ man 
wann beispielweise Autoboxing/Unboxing auftritt.

Mein Problem ist aber weniger, daß ich nur noch von "unsafed" Warnings
überhäuft werde und es mir einfach widerstrebt, Warnings auszuschalten,
sondern daß der 1.5er Bytecode nicht mehr von 1.4er JREs ausgeführt
werden kann, und ich beim Hochladen auf den Provider immer darauf
achten muß, 1.4er Code zu erzeugen.


----------



## norman (11. Mai 2006)

warum erzeugt dieser code (bei dir) unangenehmes kribbeln?


----------



## Dukel (11. Mai 2006)

Als ich gestern meine neue IX durchgeblättert habe ist mir folgendes ins Auge gesprungen und ich dachte evtl. kann das dein Problem lösen:
Web-Programmierung  Leserbrief
Anwendungsentwicklung mit IcePHP und Icegrid (S. 152)

http://www.zeroc.com/index.html


----------



## gizmo (26. Jul 2006)

@Leroy42: Schau mal hier: http://retroweaver.sourceforge.net/


----------



## Leroy42 (26. Jul 2006)

Hmmh! Wenn das stimmen sollte was RetroWeaver vollmundig verspricht:
1.5-er Java in 1.4-er Bytecode kompilieren zu können, frage ich mich, warum
Sun einen neuen Bytecode eingeführt hat (mußte!?)


----------



## Lim_Dul (26. Jul 2006)

Retroweaver schafft auch nicht alles. Annotations beispielse gehen meines Wissens nicht.


----------



## AlArenal (26. Jul 2006)

Leroy42 hat gesagt.:
			
		

> Hmmh! Wenn das stimmen sollte was RetroWeaver vollmundig verspricht:
> 1.5-er Java in 1.4-er Bytecode kompilieren zu können, frage ich mich, warum
> Sun einen neuen Bytecode eingeführt hat (mußte!?)



Der kann nur das umwandeln, was auch im alten Bytecode abbildbar ist. Generics z.B. sind kein Problem, weil es nur ne zusätzliche Typ-Checkung (nettes Denglisch) beim Kompilieren ist und kein zusätzlicher Bytecode. Sobald du 1.5er API verwendest, bringts dich natürlich nicht weiter.


> Supported 1.5 Language Features
> 
> * generics
> * extended for loops
> ...


----------



## AlArenal (26. Jul 2006)

Leroy42 hat gesagt.:
			
		

> 1.5-er Java in 1.4-er Bytecode kompilieren zu können, frage ich mich, warum
> Sun einen neuen Bytecode eingeführt hat (mußte!?)



Warum kann mein Pentium M mehr Befehle verstehen als ein Pentium, obwohl meine Software auch auf nem Pentium läuft?


----------



## Leroy42 (26. Jul 2006)

Wenn ich dich richtig verstehe, willst du darauf hinaus, daß der 1.5-er Byte-Code

a) performanter (in welcher Hinsicht auch immer) ist und

b) Möglichkeiten bietet die in einer späteren Java-Version genutzt werden.

Ich schreibe *später*, da nach der Werbung dieser Retro-Weaver-Macher
ja die 1.4-er JVM alles was 1.5 bietet ja auch ausführen lassen kann.


----------



## AlArenal (26. Jul 2006)

Es gibt diverse Änderungen am Bytecode für 1.5, aber wohl nicht derart, dass man diese nicht auch in 1.4 ausdrücken kann. Sie dienen vermutlich nur dazu den Code kleiner zu machen und die Umsetzung in Machinensprache besser optimieren zu können. 

Ich kann ja auch von Hand den Sinus eines Werts berechnen, ohne eine vorgegebene Sinus-Funktion zu nutzen.

So lange diese Abbildung auf älteren Bytecode möglich ist, kann es auch entsprechend umgedengelt werden. Was natürlich ncih geht ist auf neuere API zuzugreifen. Dazu müsstest du die neue API ebenfalls 'retroweaver'....

Kannst dir ja mal die VM Specs durchlesen und mir dann erzählen, was drin steht: 
http://java.sun.com/docs/books/vmspec/


----------



## Leroy42 (26. Jul 2006)

:shock: Soviele Buchstaben hintereinander und keine Bilder?  :shock: 

[schild=7 fontcolor=000000 shadowcolor=C0C0C0 shieldshadow=1]Ich ziehe meine Frage zurück![/schild]


----------



## Alexander Merz (1. Aug 2006)

Auch wenn die Antwort eher historischen Wert hat:

Beim Ansatz von JSR223 passiert genau das vom Fragenden erwünschte. Nämlich das PHP per DLL eingebunden wird.


----------



## AlArenal (1. Aug 2006)

Seltsamerweise scheint PHP bzgl. JSR223 unterzugehen. Zumindest aus Sicht von jemandem, der gerne alle möglichen Blogs durchpflügt, war PHP bisher nie ein Thema. Man spricht über Groovy, Jython, JRuby, BeanShell, Rhino, ... erst gestern las ich etwas über einen Port von AWK. Aber PHP? Fehlanzeige.

Schon komisch.

P.S.:
Präziser müsste ich natürlich sagen: Keiner spricht/schreibt/publiziert darüber, außer dir


----------



## Alexander Merz (8. Aug 2006)

Wahrscheinlich wirken da noch klassische Feindbilder nach. ;-) Sowohl von PHP- als auch von Java-Seite.

Wenn ich den Traffic bzgl. des Themas auf meiner Webseite verfolge, dann ist es ein relevantes Thema. Aber der Support seitens der beteiligten Parteien, ob nun Zend oder wer auch immer, ist einfach nur schlecht. Warum ist mir ein Rätsel.

PS: Meine Website ist kein Blog.


----------



## AlArenal (8. Aug 2006)

Die Erwähnung von Blogs bezog sich auch nicht auf deine Website. Nur habe ich hier rund 90 Blogs in meinem BlogBridge und da ist mir nie was untergekommen über eine Integration von PHP in Java.

Da ich derzeit u.a. auch wieder etwas mit PHP arbeiten muss, um meine Serveranbindung über XML-RPC auf vordermann zu bringen, kann ich das auch dahingehend nachvollziehen, dass PHP4 (müssen auf viele vorhandene Installationen Rücksicht nehmen) für einen Java-Coder doch schon extrem heftig ist. OO ist ein schlechter Scherz, statt eines Exception-Mechanismus ist man auf sich selbst gestellt, das ewige Prüfen auf Typen und Umwandeln, .. schrecklich. Und das sage ich, obwohl ich zuvor jahrelang meine Brötchen mit PHP verdient habe. 
Mit PHP5 sähe es wieder anders aus und einige Probleme hätte ich wohl mit beinahe jeder Skriptsprache. Aber für alle, die z.B. Java als erste Sprache hatten, kann ich mir gut vorstellen, dass denen PHP ein Graus ist. Zumal integrierte Funktionen mal überhaupt nicht intuitiv sind, weder in der Namensgebung (Hallo, Camel-Case??), noch in der Reihenfolge der Parameter. Da findet man auch im JDK einige nicht zu Ende gedachte Klassen, aber wenigstens haben wir ne eindeutige Code Completion und keine Liste von Vorschlägen, weil die IDE gerade keinen Dunst hat, von welchem Typ meine Variable ist 

Quintessenz: Ich kann Berühungsängste und Vorurteile von beiden Seiten aus verstehen und auch zu einem gewissen Grad nachvollziehen. Java und PHP sind grundverschieden. Mit PHP5 kann man zwar viele Mängel beseitigen, aber der alte Muckefuck ist eben noch immer drin. Vielleicht wäre es ratsam gewesen PHP5 komplett neu zu entwickeln, inkl. API und alte Zöpfe abzuschneiden. Soweit ich gehört habe machen es die Python-Leute so. In den Dev-Versionen testen sie auch mal neue Sachen und wenns nix bringt oder geändert werden muss, dann ändern die es auch im Nachhinein.

Ich glaub, ich schweife ab


----------

