NetBeans 15 - Strg+Z (undo) und Strg+Y (redo) funzen nicht mehr nach Start der Java-Anwendung

[inflamer]

...was auf Dauer recht nervig ist. Erst wenn man mit der Maus ins Editor-Fenster klickt, funktionieren die Shortcuts wieder.

Ich würde da ja kein Fass aufmachen, jedoch besteht das Problem nunmehr seit mehreren Major-Versionen. Vielleicht habe aber auch nur ich das Problem?

Mittlerweile ist v16 raus, aber ich wage es schon nicht mehr zu hoffen.

 

[thecain]

Wenn der Fokus auf der Java Anwendung ist, ist doch logisch das CTRL-Z in Netbeans nichts tut?

 

[inflamer]

Sorry, hab's missverständlich formuliert. Nachdem die Anwendung schon beendet ist und man bereits munter im Editor rumtippen kann, der Fokus also im Editor ist und auch andere Shortcuts wie Ctrl+C und Ctrl+V funktionieren...

DANN muss man eben nochmal zusätzlich mit der Maus reinklicken, damit auch die redo/undo Shortcuts wieder funktionieren.

 

[KonradN]

Hast du mal NB 16 ausprobiert? Gerade eben erst hat @mihe7 in einem anderen Thread etwas über NB 15 geschrieben wie buggy das in seinen Augen war und dass NB 16 erst mal einen besseren Eindruck macht. Evtl. ist der Punkt da dann auch behoben, denn das klingt ja massiv nach einem tollen Bug von NB 15.

Ansonsten ist da halt im anderen Theead etwas der Niedergang von NB Thema - ggf. ist es an der Zeit zu wechseln … Ich bin mit IntelliJ sehr zufrieden … Eclipse wird auch stark gepflegt aber ist aus meiner Sicht überkompliziert … aber wenn man sich da einmal richtig reingefuchst hat, dann ist das auch eine gute IDE (auch wenn wir hier im Forum sehr gerne Eclipse Bashing betreiben …. Und für Anfänger / Leute, die nur wenig Zeit mit der Entwicklungsumgebung zubringen ist es in meinen Augen nichts. Da ist die Frage, was man braucht und da kann ein Visual Studio Code ausreichend sein. Oder ggf. Fleet als neue IDE von JetBrains ….

 

[inflamer]

Ja, dass in NetBeans mit jeder Version genauso viele neue Bugs einfließen wie behoben werden ist ungefähr auch mein Eindruck, und das obwohl ich wohl nur einen sehr kleinen Teil aller verfügbaren Funktionen überhaupt nutze.

Einfaches Refactoring (Umbenennen) einer lokalen (!) Variable lässt sich trotz zig Major-Updates seit eh und je nur unter bestimmten Umständen rückgängig machen (welchen, weiß ich bis heute nicht), da hat man sich aber schon so dran gewöhnt, dass es fast ein Markenzeichen ist. 😁

Werde mir die anscheinend optimistisch rezipierte v16 mal ansehen, danach dann IntelliJ. Danke für den Tipp!

 

[mihe7]

Oder ggf. Fleet als neue IDE von JetBrains ….

... intelligente IDE​

Vermutlich ist NB einfach zu intelligent für uns 😛

 

[White_Fox]

Einfaches Refactoring (Umbenennen) einer lokalen (!) Variable lässt sich trotz zig Major-Updates seit eh und je nur unter bestimmten Umständen rückgängig machen (welchen, weiß ich bis heute nicht), da hat man sich aber schon so dran gewöhnt, dass es fast ein Markenzeichen ist. 😁

Ich meine, daß das in NB8 kein so großes Problem war.

 

[Neumi5694]

Einfaches Refactoring (Umbenennen) einer lokalen (!) Variable lässt sich trotz zig Major-Updates seit eh und je nur unter bestimmten Umständen rückgängig machen (welchen, weiß ich bis heute nicht), da hat man sich aber schon so dran gewöhnt, dass es fast ein Markenzeichen ist. 😁

Ich musste mich nie daran gewöhnen, bei lokalen Variablen hatte ich nie ein Problem. Nur an records scheitert er.

Was mich mehr stört, ist, dass sich die Zwischenablage hin und wieder vom Glauben abwendet, bzw. sich vom Betriebssystem löst.
Netbeans und das restliche OS haben dann jeweils eine eigene Zwischenablage. Da hilft dann nur ein Neustart von NB.

... und der interne Compiler wertert myCollection.forEach(...) oder Collections.unmodiFiableList(myList)nicht als Lesezugriff und warnt davor, dass in die Collection nur geschrieben wird, aber nie daraus gelesen wird :s

 

[mihe7]

Da hilft dann nur ein Neustart von NB.

Es bessert sich langsam, s. auch https://github.com/apache/netbeans/pull/4774

... und der interne Compiler

Jetzt habe ich mal genauer nachgelesen und verstehe allmählich, warum es seit Apache vermehrt zu Problemen kam/kommt(?): mal wieder rechtlicher Müll.

Kurz: es war fraglich, ob und in welcher Form nb-javac (Oracle, GPL+CPE) in NB (ASF, ASL) integriert werden darf, da nb-javac von Oracle nicht an Apache gespendet wurde (https://issues.apache.org/jira/browse/LEGAL-563). Allerdings wird weiterhin das von Oracle gewartete nb-javac verwendet, wenn ich es richtig verstanden habe. Insgesamt ist mir das alles noch nicht wirklich klar, denn das Projekt hat den letzten Commit vergangenes Jahr (wegen JDK 17) erhalten, wie kann es dann sein, dass in NB ein nb-javac mit JDK 19 Unterstützung ausgeliefert wird?!? Das werde ich mir noch im Detail anschauen, aber nicht heute 🙂