Eclipse Neon 1 – Standard-JSDT mit Schwächen – zusätzliche Plugins

Im September 1016 wurde die neue Eclipse-Version NEON I veröffentlicht. Ich hatte mir zuvor im Sommer bereits die R-Version angesehen. Während das PDT-Plugin für PHP unter NEON gut aussieht und seine Dienste auch für PHP 7 in gewohnter Weise leistet, kam bei einem Blick in die JSDT-Ecke eher ein wenig Enttäuschung auf.

Zwar gilt:
Der neue JS-(Esprima)-Interpreter kann sehr gut mit "ECMAScript 6"-Syntax [ES6]. Auch der Outline-Bereich funktioniert z.B. für die Anzeige definierter Objekt-Methoden/Funktionen, die über die neue ES6-Syntax mit "calss"-Statements angelegt werden, perfekt. Die gesamte Hierarchie von Objekt-Methoden/Funktionen und -Variablen wird dabei angezeigt. Gut gefallen haben mir auch der Debugger, der Support von "node.js" und auch ein paar andere neue Features (siehe etwa https://www.youtube.com/watch?v=UxGwu2adzIc). Generell ist es begrüßenswert, dass engagierte Leute versuchen, JSDT auf ein neues, zeitgemäßes Niveau zu hieven !

Aber: Wer hat schon alle seine JS-Codes auf die ES6-Syntax umgestellt? Zumal nicht alle von Kunden genutzten Browser-Versionen ES6 unterstützen.

Und dann kommt beim originalen unmodifizierten JSDT von NEON ein wenig Frust auf:

Hat man seine Objekt-Methoden über die klassische Syntax und Definitionen in der Prototype-Chain festgelegt, wird die nächste Hierarchieebene "Objekt" => Funktionen und Variablen" für ein Objekt im Outline-Fenster leider nicht mehr angezeigt. Der Outline-View für Objekte endet dann auf der Ebene der Objektnennung - nur der oberste Level wird angezeigt, also das Objekt selbst, nicht aber seine Variablen oder Methoden/Prototype-Funktionen. Ich habe das gerade nochmal für ein frisch heruntergeladenes NEON I überprüft.

Das Outline-Tool liefert für ES(≤5)-Code also leider nicht mehr die Funktionalität, die man von Mars 2 und Vorgängerversionen gewohnt war. Ich weiß nicht, ob sich die Eclipse-JSDT-Entwickler darüber im Klaren sind, dass das fast einem KO-Kriterium für die Benutzung entspricht? Eine voll funktionierende Outline-Umgebung mit mindestens zwei funktionierenden Hierarchie-Ebenen ist für ein schnelles organisiertes Arbeiten bei komplexen Codes ein Muss.

Ein Test-Beispiel

Folgender simpler Testcode zeigt das Problem auf:

var z = 7; 
var GOCR = new GOCC();  

var xas = function() {
  var beta = GOCR.beta(); 	
	
  var yas = function () {
	  var loc_num = GOCR.alpha(); 	
	  var zzz = function() {
		  var fff = 'fff'; 
	  }; 
  };  
}; 

class UUC {
	constructor (x) {
		this.x = x; 
	}
	ucc_alpha() {
		this.y = 'yyyy'; 	
	}
}

function GOCC() {
	this.ax_str = 'ufo'; 
	this.vv_ay  = new Array('Enlarge'); 
}

	GOCC.prototype.alpha = function() {
		this.a_num = 7;  
	};
	
	GOCC.prototype.beta = function() {
		this.b_num = 8; 
		return this.bnum; 
	};

 
Mit dem unmodifiziertem JSDT von NEON I führt dies zu folgender Darstellung im Outliner:

not_expanding_object_prototype_functions

Man erkennt, dass zwar verschachtelte Funktionsstatements über mehrere Hierarchieebenen hinweg korrekt aufgelöst werden. Auch die Methoden der "UUC"-Klasse werden noch dargestellt. Die Funktionen aber, die einem Funktionsobjekt über dessen Prototype zugeordnet wurden, werden jedoch im Gegensatz zum JSDT von Eclipse Mars nicht im Outline-View angezeigt.

Workaround mittels "Webclipse JSjet" und "Tern"

Diejenigen, die nicht auf eine originäre Lösung im Rahmen der weiteren JSDT-Entwicklung warten wollen, können ggf. auf das Webclipse JSjet-Plugin zurückgreifen (Eclipse Repository: https://www.genuitec.com/updates/webclipse/ci/). JSjet greift intern auf Tern-Funktionalität zurück. Nach der Installation bietet der Outliner für Objekte bzw. Objekt-Konstruktor-Funktionen wenigstens zwei Ebenen an. Allerdings muss man sich dafür nach jedem Neustart von Eclipse mit etwas nerviger Werbung für Webclipse und die Fa. Genuitec auseinandersetzen - und mir persönlich sind die Lizenzbedingungen nicht vollständig klar. Ein Blick in diese Ecke lohnt sich aber durchaus.

Ich habe testweise auch die wichtigsten "tern"-Plugins aus dem aktuellen Repository "http://oss.opensagres.fr/tern.repository/1.2.0/" installiert. Insgesamt habe ich dadurch neben einer bzgl. Class und Prototype verbesserten Outline-Darstellung auch eine vernünftige Autocompletion-Unterstützung für jQuery erhalten. Dies ist umso wichtiger, als der Entwickler für das bisher bewährte JSDT-jQuery-Plugin nach eignen Ausführungen auf seiner Github-Seite Probleme mit Neon hat und um Unterstützung bittet.

In einer Testinstallation versammeln sich dann neben dem JSDT-Plugin u.a. folgende Plugins für die JS-Entwicklung:
tern_plugins

Mit dem Resultat kann man leben:
expanding_object_prototype_functions_with_tern
Ich verstehe nicht, dass das, was da geboten wird, nicht schon in den Standard übergegangen ist, da ja beim neuen JSDT-Team auch jemand von der Fa. Genuitec, die hinter Webclipse steckt, dabei zu sein scheint.

Fairerweise muss man sagen, dass die Auflösung über mehrere Ebenen hinweg unter dem Standard JSDT für verschachtelte Funktionen sogar besser funktioniert als mit JSjet und Tern. Leider aber nicht für Objekt-Konstruktoren und Prototype-Funktionen nach alter ECMA-Syntax.

Ich hoffe auf ein noch besseres JSDT in der Neon 2 Version.

Hilfreiches Eclipse Plugin: wtp-webresources

Ich versuche ja gerade, meine Frau dazu zu bringen, statt des proprietären und nicht linux-tauglichen und wenig stabilen Dreamweavers die IDE Elipse für HTML und CSS Coding zu benutzen. Zur Auswahl stehen dort die Web Standard Tools (WST) oder z.B. das Aptana Studio Plugin. Nun zieht die Installation des Aptana Plugins immer noch einige unangenehme Nebeneffekte nach sich, so dass man sich lieber mit den Editoren der nativen Eclipse Web Developer Tools begnügen möchte.

Ein Nachteil des WST Eclipse HTML Editors für Eclipse-Umsteiger ist u.a. folgender:

Man erhält zwar Code Assist Vorschläge bzgl. elementarer CSS2- oder CSS3-Anweisungen für Inline-Styles. Beim Editieren des "class"-Attributs eines HTML-Tags erhält man jedoch keine Assist-Angebote zu bereits definierten Style-Anweisungen für Classes, die in CSS-Dateien eines Eclipse-Projekts enthalten sind - auch dann nicht, wenn man solche CSS-Dateien bereits explizit im HEAD-Bereich der HTML-Datei eingebunden hat. Umgekehrt erhält man bei einem Hover über die Klassendeklaration eines HTML-Tags keine Informationen zu den zugehörigen Style-Festlegungen.

Ähnliche Defizite gibt es im Bereich der Ergänzung von Bild-, CSS-File- und JS-File-Ressourcen. Hier ließen sich Content Assist Angebote ja prinzipiell über die Inhalte der Projektverzeichnisse zusammenstellen.

Das Plugin "wtp-webresources" behebt all diese Schwächen und ist damit ein wirklich nützliches, empfehlenswertes Helferlein für Eclipse Mars. Siehe:
https://github.com/angelozerr/eclipse-wtp-webresources

Ob das meine Frau überzeugen wird, weiß ich noch nicht - der nächste Punkt, den sie im Vergleich mit Dreamweaver mit Sicherheit vermissen wird, ist eine Darstellung der effektiv wirksamen CSS-Styles für ein HTML-Tag aus der Kombination der für das Tag festgelegten "id"-bezogenen, "class"-bezogenen Styles, aktuellen Inline-Styles und zugehöriger Spezifizitätsregeln. Wäre auch in Eclipse nützlich ....

Opensuse Leap 42.1 und 13.2 – aktuelle Versionen des freshplayerplugin-Pakets führen zum Crash von Eclipse mit GTK2

Es gibt Probleme, deren Ursachen sind schwer zu finden und können einen in den Wahnsinn treiben. So zuletzt das Phänomen, dass Eclipse mit GTK2 nach Updates sowohl von Opensuse 13.2 als auch Opensuse Leap 42.1 permanent und zunächst scheinbar erratisch abstürzten.

Interessanterweise tauchen die Probleme mit Eclipse unter GTK3 nicht auf. Allerdings zeigt die Eclipse UI unter GTK3 noch einige unschöne Grafik-Probleme.

Es dauerte eine Weile, bis ich herausfand, dass die Abstürze von Eclipse/GTK2 nur auftraten, wenn ich Content Assist Funktionalitäten benutzte (was ich natürlich sehr regelmäßig tue) und dabei Zusatzinformationen zu Elementen der Vorschlagsliste angezeigt wurden. Typischerweise ist es so, dass diese Zusatzinformationen aus HTML-Vorgaben gerendert werden. Die Java Runtime JVM nutzt hierzu "webkit"-Funktionalitäten (der Umgebung).

Es dauerte noch einige Zeit mehr, bis ich herausfand, dass das Problem auf einer frischen Installation von OS 13.2 oder LEAP 42.1 nicht auftrat - wohl aber nach einer Reihe von Updates der Opensuse-Umgebung. Leider ist es durchaus schwierig, herauszufinden, welches Paket unter hunderten genau der Verursacher der Probleme ist. Dass es mit Web/HTML-Rendering zu tun haben musste, war aber klar.

Durch eine Backtrace-Analyse des JVM-Absturzes kam ich heute einen substanziellen Schritt weiter:

Die erhaltenen Absturz-Informationen der JVM zeigten, dass im Rendervorgang auch eine "freshwrapper"-Bibliothek tangiert wurde - genauer:
"/usr/lib64/browser-plugins/libfreshwrapper-pepperflash.so" aus dem Paket freshplayerplugin.

Das Paket "freshplayerplugin" liefert einen nützlichen Firefox-Wrapper für Chromes/Chromiums "pepper-flash"-Plugin. Letzteres ermöglicht das Abspielen von Flash-Inhalten auch unter Firefox - das ist u.a. nützlich für Live-Streams des einen oder anderen Fernsehsenders, der bislang noch nicht auf vernünftige Formate umgestellt hat.

Ich hatte das Paket "freshplayerplugin" unter Leap 42.1 und OS 13.2 im Zuge von Updates in der aktuellsten Variante "0.3.4-20.1" vom Packman-Repository installiert.

Tatsächlich zeigte sich, dass mit einer Installation der Paketversion "0.3.2" aus den jeweiligen Hauptrepositories von SuSE die Eclipse-Absturz-Probleme unter Opensuse Leap 42.1 verschwanden. Bzgl. OS 13.2 muss ich mich noch kundig machen.

Ich hoffe, diese Info zumindest zu Leap 42.1 hilft auch anderen Betroffenen, die Eclipse mit GTK2 nutzen wollen.