Re: Neuer VB Compiler

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hallo Ulrich,

Das Projekt ist noch nicht mal fertig :-) Soll nächstes Jahr in einer
ersten Version öffentlich verfügbar sein.

Soll... hmmm... weiß jemand, wie stabil Sun im Allgemeinen mit derartigen
Ankündigungen ist?

Keine Ahnung. Aber es geht hierbei wohl auch um die künftige Positionierung von Java gegenüber .NET, und Sun möchte wohl zum einen das Multilanguagefeature von .NET nun auch in Java ernsthaft und offiziell unterstützen und zum anderen Entwickler zum Umstieg von .NET-Tools zu Java-Tools bewegen. Das läßt hoffen, daß dabei auch die Wünsche umstiegs- oder einstiegswilliger Entwickler verstärkt berücksichtigt werden.

Wieso sollte man allein aus der Tatsache, dass Sun Entwickler zum Umsteigen bewegen will, schließen können, dass sie auf Wünsche eingehen werden, und das auch noch "verstärkt"? Schließlich will auch Microsoft Entwickler zum Umsteigen bewegen. Da brauchts doch irgendwie noch ein wenig mehr an Fakten, um einen solchen Schluss ziehen zu können, oder?

Es gab eine erste Demo der geplanten Fähigkeiten. Dabei wurde unter anderem in der Netbeans-IDE eine neue (minimale) VB-App erstellt: zwei Buttons, ein Textfeld und Eventhandlercode. Die Erstellung lief so wie unter VB gewohnt: neues Form anlegen, aus dem Toolkit die Controls auf die Form ziehen, per Klick auf die Controls die Eventhandlergerüste anlegen und dann im Codeeditor mit Code füllen. Das Toolkit soll alle VB-Standardcontrols zur Verfügung stellen (incl. zB FileListBox etc).

Klingt ja vielversprechend... Hm... nur die Standard-Controls? Und was ist mit den Common- und den Dialog-Controls? Und was ist mit 3rd-Party-OCXen?

...
Nein. UI-Programmierung wird 1:1 übernommen. Da, wo VB intern COM verwendet, wird die gleiche Funktionalität über die Java-Runtime zur Verfügung gestellt. zB wenn man mit New eine VB-Instanz einer VB-Klasse erstellt, verwendet VB dafür intern COM, VBforJava intern die Java-Runtime-Methoden (wobei die VB-Syntax aber bestehen bleibt). Das soll auch für Dlls funktionieren, wenn diese als Source vorliegen. Es wird dann keine Windows-COM-Dll erzeugt, sondern entsprechende kompilierte Java-Klassen. Diese sind aber wie gewohnt unter VB anzusprechen (mit New etc). Die interne Umsetzung, die ja COM nicht verwendet, bleibt dabei verborgen.

Und was ist mit 3rd-Party-COM-DLLs, ganz zu schweigen von Standard-DLLs?

Wenn man also eine VB-Applikation hat, die zudem einen Teil ihrer Funktionalität in VB-Dlls ausgelagert hat, und für alles die Sourcen vorliegen, soll diese App inklusive der "Dlls" 1:1, ohne ein Bit am Sourcecode ändern zu müssen (inklusive der Forms), unter VBforJava lauffähig sein. Und zwar plattformunabhängig. Seit wann kann .NET das?

..NET kann das nicht, klar. Aber ist das wirklich so entscheidend? Denn dieser Idealfall einer Pur-VB-Code-Anwendung ohne jeden Griff unter die Haube ist meiner Einschätzung nach zumindest bei professionell( geschrieben)en Anwendungen eher eine Rarität. Zumindest in meinem Bestand gibt es keine.

Direkte API-Aufrufe und Aufrufe von Klassen in binären COM-Dlls bleiben natürlich plattformabhängig und der aufrufende Code muß auch angepaßt werden.

Eben...

Bezüglich des Engagements der VB-Community bei der Einbringung von Wünschen
sehe ich die Gefahr, dass womöglich unter dem Wunsch auch hier "endlich mal
alte Zöpfe abzuschneiden" und einer möglicherweise vorhandenen
Unerfahrenheit auf Seiten Suns mit tatsächlichen VB-Gegebenheiten die
versprochene Kompatibilität doch mehr oder weniger leiden könnte...

Eines der Ziele laut Sun ist es, VB-Entwicklern zu ermöglichen, ihre VB*classic* Kenntnisse verwenden zu können, um damit unter einer Java-Runtime Programme zu entwickeln. Es wird also nicht erwartet, daß diese sich erst neue Kenntnis aneignen müssen. Das geht natürlich nur, wenn VB classic 1:1 unterstützt wird. Erweiterungen sind trotzdem möglich und auch angedacht. Diese sollen aber *wahlfrei* sein. Also auf Wunsch strikt VB classic oder mit Erweiterungen. Und jetzt sag nicht, daß das nicht geht. Das geht sehr wohl.

Sicher geht das.

Und mit dem "endlich mal alte Zöpfe abzuschneiden" zeigst Du deutlich, daß Du immer noch nicht kapiert hast, worum es vielen VB-Entwicklern inklusive meiner Wenigkeit geht.

Da hast Du mich aber missverstanden. Das "alte Zöpfe abschneiden" habe ich lediglich als Gefahr gesehen, dass eine zu eingehende Berücksichtigung von Entwicklerwünschen Sun dazu verleiten könnte, letztlich doch auch die angestrebte 1:1-Kompatibilität platzen zu lassen.

Ich habe nichts dagegen, alte Zöpfe abzuschneiden. Ich hätte auch nichts dagegen, wenn .NET ohne VB.NET ausgeliefert werden würde. Die so geschätzten RAD-Features sind auch mit C# möglich. Was mich dagegen aufregt, ist, daß man sich nicht die Mühe gemacht hat, für den *Übergang* VB classic unter .NET zu ermöglichen.

Vermutlich hätte Microsoft das besser machen können. Das denke ich auch, aber ich rege mich deswegen nicht auf - das ist wohl der wesentliche Unterschied in unseren Standpunkten. Und ich vermute, dass man sich Microsoft heute im Rückblick darauf, dass erst jetzt mit der 2005er Version enrsthaft das Migrations-"Marketing" angegegangen worden ist, auch denkt, dass man vielleicht doch eine Zwischenlösung hätte anbieten sollen.

Was mich dagegen aber eher "aufregt", ist, dass nach so verhältnismäßig langer Zeit immer noch, obwohl faktisch wohl nichts mehr daran zu rütteln ist, immer noch Energie fürs "Aufregen" (um nicht zu sagen, "Jammern") verschwendet wird.

- Und all diejenigen, deren Vertrauen gegenüber MS gewaltig gelitten hat
(wg. des gewaltsamen Abwürgens von VB) und deshalb zwar sehen, daß
langfristig eine Umstellung nötig ist, dies aber ungern wieder mit
MS-Tools tun möchten, haben nun eine ernstzunehmende Alternative.

Setzt man hier nun auf Sun, begibt man sich u.U. vom Regen in die Traufe. Sich aus Frust über die Abhängigkeit von Microsoft nun in die Abhängigkeit von Sun begeben zu wollen, halte ich für wenig rational.

Quark. Sobald Du Software entwickelst und dazu notwendigerweise irgendwelche Tools verwendest, bist du schon abhängig. Das ist rational, sich darüber im klaren zu sein.

Wenn Du Dir darüber im klaren bist - schön. Viele Stimmen in den Diskussionen bisher lassen aber eher vermuten, dass es bei weitem nicht allen so klar ist, bzw. gewesen war, als sie sich auf VB-Classic eingelassen haben.

Rational ist es auch, sich die Tools zu suchen, die einem am besten behagen und produktiv sind (zB möglichst wenig Aufwand für eine initiale Codeumstellung benötigen). Und rational ist es, dabei auf ein langfristig unterstütztes Tool zu setzen und nicht auf Tools, die morgen schon vom Markt verschwinden können oder deren Entwickler nicht die Kapazitäten haben, ihr Tool laufend zB gegen die sich ständig wandelnden Plattformen upzudaten. Wer das nun liefert, ist mir, mit Verlaub, sch*egal.

Und bei Sun bist Du also rational der Meinung, dass die die Ankündigung so wie eben angekündigt wahr machen werden, dass es langfristig unterstützt werden wird, dass es nicht morgen (... d.h. übermorgen, da es ja erst "morgen" erscheinen soll...) schon vom Markt verschwindet, dass es laufend gegen die sich wandelnden Plattformen upgedatet werden wird?

Die Frage ist auch, wie stabil dann irgendwann im nächsten Jahr die erste Version sein wird

Würde genauso stabil wie .NET1 reichen?

Wenn die das ohne die 2 Beta-Jahre, die .NET 1 vor der Veröffentlichung 2002 hinter sich hatte, hinbekommen sollten, wäre das bewunderswert - also Antwort: ja.

(so es denn nicht bloß bei der Ankündigung und
Hoffnung darauf bleibt), oder wie lange es dann noch dauern wird, bis eine tatsächlich taugliche, stabile Version verfügbar sein wird.

So wie .NET2 nach 5 Jahren?

2005 - 2002 macht bei mir 3 Jahre... aber sei's drum - Antwort: ja.

Das hieße aber auch, dass dieses VBforJava so etwa erst 2010 wirklich produktiv nutzbar wäre.

Sollte Microsoft die Ankündigung wahr machen, alle 18 Monate eine neue VS-Generation mit neuen .NET-Essentials auf den Weg zu bringen, dürften dann aber Welten hinsichtlich der Produktivität eines stabilen VB-Classic-Nachbaus und dem dann aktuellen .NET liegen...

Als direkte, echte Alternative zu VB.NET sehe ich das aber nicht - jegliche vergleichende Diskussion zu VB.NET halte ich daher auch für überflüssig.

Es soll ja auch nicht mit VB.NET verglichen werden, da es nicht vegleichbar ist. Es ist ein anderer Ansatz.

Warum argumentierst Du dann ständig mit .NET vergleichend?

Grundsätzlich finde ich es aber interessant, die Idee, unter verschiedenen Sprachen gegen ein umfassendes Framework zu programmieren, aufzugreifen - hier nun unter einem Basic gegen das Java-Framework, also eine interessante Option einer zusätzlichen Plattform, die man dann ebenfalls mit grundlegenden Basic-Skills bedienen kann.

Ja. Zuerst hat Sun mit einer modernen, pointerlosen Sprache und einem mächtigen, plattformunabhängigem Framework Maßstäbe gesetzt. Dann hat MS nachgezogen und die Fähigkeit, das Framework unter verschiedenen Sprachen zu bedienen, zusätzlich (schon by design) vorgesehen. Dagegen ist auch nichts einzuwenden, leider fiel die Plattformunabhängigkeit dabei weg (und jetzt bitte nicht Mono erwähnen, das ist nicht von MS). Und nun zieht Sun seinerseits nach und schwenkt auf die multiple languages - one framework Geschichte ein (offiziell, mit Sun Unterstützung). Damit hätte Sun wieder die Nase vorn.

Seit wann bedeutet ein Einschwenken/Gleichziehen/Nachahmen "Nase vorn"? Das kann ich so jetzt nicht ganz nachvollziehen. Wegen der Plattformunabhängigkeit? Nun ja... warum werden dann nicht die verbreitetsten (und populärsten) plattformübergreifend verfügbaren Anwendungen bisher schon noch nicht in Java geschrieben? Mozilla/Firefox, Opera, Open Office, Apache, PHP-Runtime, Perl-Runtime u.v.v.v.v.v.m.? (Nein, ich will jetzt sicher keine pro-/kontra Java-Diskussion anfangen...)


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin
http://www.aboutvb.de

.

Quantcast