Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Android-App für Raspberry…

Java...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Java...

    Autor: rmfr 24.08.17 - 11:05

    Über die Jahre habe ich es immer mal wieder mit Java versucht, kann mich aber trotz guten Willens immer noch nicht mit der Sprache anfreunden. Quelltext erscheint mir vergleichsweise langatmig und voll mit "Coderauschen", ohne IDE wäre es eine Zumutung effizient Java zu programmieren.

    Auf Servern kommen Java-Prozesse oft speicherhungrig daher, brauchen gefühlte Ewigkeiten zum Starten und Beenden, und die JVM möchte vorab Limits für den nutzbaren Speicher wissen.

    Vielleicht bin ich auch aus historischen Gründen verheizt (Java-Applets im Browser, Desktop-Anwendungen).

    Bin ich der Einzige mit "Java-Allergie"? :-)



    1 mal bearbeitet, zuletzt am 24.08.17 11:05 durch rmfr.

  2. Re: Java...

    Autor: Trollversteher 24.08.17 - 11:27

    >Über die Jahre habe ich es immer mal wieder mit Java versucht, kann mich aber trotz guten Willens immer noch nicht mit der Sprache anfreunden. Quelltext erscheint mir vergleichsweise langatmig und voll mit "Coderauschen", ohne IDE wäre es eine Zumutung effizient Java zu programmieren.
    >(...)
    >Bin ich der Einzige mit "Java-Allergie"? :-)

    Geht mir auch so. Alleine die umständliche Implementierung von Gettern und Settern - "langatmiges Coderauschen" ist da genau die richtige Bezeichnung - wenn man zB mit C# vergleicht:

    Aus

    public string Name { get; set; }

    wird in Java:

    private String name;

    publich void setName(String name)
    {
    this.name = name;
    }

    public String getName()
    {
    return this.name
    }




    1 mal bearbeitet, zuletzt am 24.08.17 11:37 durch Trollversteher.

  3. Re: Java...

    Autor: Pete Sabacker 24.08.17 - 11:34

    rmfr schrieb
    -----
    > Bin ich der Einzige mit "Java-Allergie"? :-)

    Nein :)

  4. Re: Java...

    Autor: teenriot* 24.08.17 - 13:16

    Man muss es im Detail nicht mögen, aber es hat alles seinen Grund. Bei Java gibt es nun mal keinen unsichtbaren Code und Makro-Labyrinthe gibt es auch nicht. Ja, dadurch ist der Quellcode langatmiger, aber auch wartungsfreudiger, erst recht wenn nicht der Autor warten muss. So ein getter oder setter ist in einer IDE mit unter 10 Tastaturanschlägen geschrieben. Ich sehe da kein Problem.

  5. Re: Java...

    Autor: vinylger 24.08.17 - 13:36

    Entscheidend ist, beim refactoring darauf zu achten, die Getter und Setter (ggf. von Hand) anzupassen. Bei Klassen mit vielen davon eine Zumutung - dann doch lieber "unsichtbar", denn wir wissen alle, dass es das gleiche tut.

  6. Re: Java...

    Autor: teenriot* 24.08.17 - 13:52

    Getter/Setter im Block markieren, löschen, neu generieren lassen, dauert 10 Sekunden.

    Getter/Setter sind so eine Trivialität, das eine ernsthafte Bewertung einer Sprache auf Grundlage dessen meiner Meinung nach keinen sinn ergibt. Die echten Knackpunkte findet man woanders.



    1 mal bearbeitet, zuletzt am 24.08.17 13:53 durch teenriot*.

  7. Re: Java...

    Autor: rmfr 24.08.17 - 19:54

    teenriot* schrieb:
    --------------------------------------------------------------------------------
    > Bei Java gibt es nun mal keinen unsichtbaren Code (...)
    Ist das nicht einer der Gründe Java zu benutzen? :-)

  8. Re: Java...

    Autor: Skruzzls 24.08.17 - 20:39

    Java hat durchaus seine Vorzüge, aber das Problem, dass ich bei Java sehe ist einfach, dass es, zumindest von dem was ich mitbekomme, nicht wirklich weiterentwickelt wird. Wenn man Java mit C# vergleicht sieht man massiv wie Java hinterhinkt. Allein schon die Doku ist bei MSDN um einiges besser als bei Oracle. Das Einzige, dass mich wirklich dazu bewegt in Java zu schreiben ist a) IntelliJ als IDE (deutlich mächtiger als VS) und b) Android -Programmierung. Für Crossplattform-Entwicklung nehme ich inzwischen lieber mal C# zu Hand, da JVM zwar auf allem möglichen läuft, aber teilweise auch nur "läuft".

  9. Re: Java...

    Autor: tsp 25.08.17 - 07:33

    Ich muss sagen, dass ich mir anfangs mit Java auch "schwer" getan habe (und die Sprache einfach nicht mochte). Gerade auf Android und mit einem tieferen Verständnis für die Designentscheidungen (und damit, viele andere Sprachen kennen gelernt zu haben) muss ich allerdings sagen, dass ich begonnen habe Java für einige Aufgabenfelder wirklich zu mögen - vor Allem, da sich gerade einige der häufig verwendeten Pattern mit Java schön und übersichtlich umsetzen lassen.

    Klar, bei der Entwicklung von C# wurde viel von Java dazu gelernt, weshalb die Sprache an sich auch gut ist, aber gerade die Tatsache das Java wirklich schnell und ohne Probleme portabel auf verschiedensten Plattformen läuft (ich weiß, das funktioniert mit C# prinzipiell auch) und der Tatsache, dass man sich bei den meisten Anwendungen nicht mit zig Runtime Library Versionen herumschlagen muss weil sie prinzipiell abseits von Android abwärtskompatibel sind finde ich persönlich sehr gut. Was unter Java natürlich etwas unangenehm ist (verglichen mit den .NET Sprachen) ist das Einbinden von native Code.

    Was natürlich etwas ungut an den Managed Sprachen (aber da macht auch C# keine Ausnahme) ist, ist z.B., dass man Assemblies bzw. Classes nach dem initialen Laden nicht mehr verlässlich aus dem Speicher verdrängen und z.B. durch neue Versionen ersetzen kann - es gibt da zwar prinzipiell Tricks mit Java Class Loadern, es garantiert aber niemand, dass die auch funktionieren; bei .NET Assemblies wird's meines Wissens nach überhaupt unmöglich, wenn man mehrere Assemblies mit dem selben Namespace nacheinander laden wollen würde. Und was Java natürlich ebenfalls fehlt ist eine gute Dokumentation, wie man die häufiger verwendeten JVMs dazu bekommt weniger Speicherhungrig zu arbeiten bzw. einmal überhaupt Speicher wieder an das OS freizugeben - möglich ist das allerdings, auch wenn Java natürlich allgemein prinzipbedingt Speicherhungriger ist als native Sprachen ...

    IMHO ist allerdings eine gute IDE gerade wegen dem Umfang der Standard Library genauso wie bei den .NET Sprachen Pflicht.

  10. Re: Java...

    Autor: RicoBrassers 25.08.17 - 07:47

    rmfr schrieb:
    --------------------------------------------------------------------------------
    > teenriot* schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Bei Java gibt es nun mal keinen unsichtbaren Code (...)
    > Ist das nicht einer der Gründe Java zu benutzen? :-)

    Doch, ist es. Schreibt teenriot aber auch so in seinem Kommentar. ;)

  11. Re: Java...

    Autor: rmfr 25.08.17 - 10:54

    RicoBrassers schrieb:
    --------------------------------------------------------------------------------
    > rmfr schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > teenriot* schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Bei Java gibt es nun mal keinen unsichtbaren Code (...)
    > > Ist das nicht einer der Gründe Java zu benutzen? :-)
    >
    > Doch, ist es. Schreibt teenriot aber auch so in seinem Kommentar. ;)
    Sorry, hab das unklar formuliert: "Unsichtbarer Code" ist einer der Gründe Java zu benutzen - man muss sich um viele Dinge eben nicht kümmern.

  12. Re: Java...

    Autor: slacki 25.08.17 - 15:17

    Mal abgesehen davon, dass getter/setter absolut gegen OO verstossen und ein code-smell (in den meisten Fällen) sind, gibt es auch Libraries die einem das abnehmen, wie zb lombok.
    Und wer 10 Anschläge braucht um für eine Klasse alle getter/setter zu generieren, der kann nicht mit seiner IDE umgehen ;)
    Mit Intellij/Netbeans brauche ich dafür so um die 3-4 "Anschläge", einmal zum öffnen des Dialogs für Refactoring (oft alt+ins), dann "generate getter/setter" auswählen und nochmals enter drücken zum bestätigen.

  13. Re: Java...

    Autor: Das Osterschnabeltier 25.08.17 - 21:47

    teenriot* schrieb:
    --------------------------------------------------------------------------------
    > Man muss es im Detail nicht mögen, aber es hat alles seinen Grund. Bei Java
    > gibt es nun mal keinen unsichtbaren Code und Makro-Labyrinthe gibt es auch
    > nicht. Ja, dadurch ist der Quellcode langatmiger, aber auch
    > wartungsfreudiger, erst recht wenn nicht der Autor warten muss. So ein
    > getter oder setter ist in einer IDE mit unter 10 Tastaturanschlägen
    > geschrieben. Ich sehe da kein Problem.

    +1
    Bei meiner IDE gehts mit 5 Tastenanschläga. Und wer vernünftige Software (mit Java) entwickeln will kommt an einer IDE so oder so nicht vorbei.

  14. Re: Java...

    Autor: Das Osterschnabeltier 25.08.17 - 22:45

    slacki schrieb:
    --------------------------------------------------------------------------------
    > Mal abgesehen davon, dass getter/setter absolut gegen OO verstossen und ein
    > code-smell (in den meisten Fällen) sind, gibt es auch Libraries die einem
    > das abnehmen, wie zb lombok.
    > Und wer 10 Anschläge braucht um für eine Klasse alle getter/setter zu
    > generieren, der kann nicht mit seiner IDE umgehen ;)
    > Mit Intellij/Netbeans brauche ich dafür so um die 3-4 "Anschläge", einmal
    > zum öffnen des Dialogs für Refactoring (oft alt+ins), dann "generate
    > getter/setter" auswählen und nochmals enter drücken zum bestätigen.

    Kann ich auch nur zustimmen.
    Wobei Lombok halt auch eine weitere Library ist die man mitschleppen muss. Ist Abwägungssache.

  15. Re: Java...

    Autor: monito 26.08.17 - 15:02

    Ist auch eine Frage der Philosophie. Ich denke, wenn man sich daran gewöhnt hat OOP zu denken, fehlt es oft schwerer, sich in andere Sprache mit anderem Paradigma und es ist auch etwas anderes, wenn man auf Desktop, Server, Webentwicklung macht. Alles hat seine Berechtigung denke ich, aber das leie jetzt mit irgendein Editor Javacode schreiben finde ich witzig

  16. Re: Java...

    Autor: teenriot* 27.08.17 - 12:52

    slacki schrieb:
    --------------------------------------------------------------------------------
    > Mal abgesehen davon, dass getter/setter absolut gegen OO verstossen und ein
    > code-smell (in den meisten Fällen) sind

    Na das erklär mal genauer.

    > Und wer 10 Anschläge braucht um für eine Klasse alle getter/setter zu
    > generieren, der kann nicht mit seiner IDE umgehen ;)
    > Mit Intellij/Netbeans brauche ich dafür so um die 3-4 "Anschläge", einmal
    > zum öffnen des Dialogs für Refactoring (oft alt+ins), dann "generate
    > getter/setter" auswählen und nochmals enter drücken zum bestätigen.

    Lächerlich.
    Das kann man mit Eclipse genauso machen.
    Ich bin mit meiner Methode trotzdem schneller.
    Das weiß man aber nur wenn man mit seiner IDE umgehen kann.

  17. Re: Java...

    Autor: Pete Sabacker 27.08.17 - 14:02

    teenriot* schrieb:
    --------------------------------------------------------------------------------
    > Lächerlich.
    > Das kann man mit Eclipse genauso machen.
    > Ich bin mit meiner Methode trotzdem schneller.
    > Das weiß man aber nur wenn man mit seiner IDE umgehen kann.

    Die Java-Elite hat gesprochen.

  18. Re: Java...

    Autor: teenriot* 27.08.17 - 16:01

    Fische, frische Fische ...

  19. Re: Java...

    Autor: RicoBrassers 28.08.17 - 08:26

    slacki schrieb:
    --------------------------------------------------------------------------------
    > Mal abgesehen davon, dass getter/setter absolut gegen OO verstossen

    Moment, waren es nicht Getter und Setter, die aufgrund der Datenkapselung definitiv Teil von OOP sind?

  20. Re: Java...

    Autor: gadthrawn 28.08.17 - 10:05

    RicoBrassers schrieb:
    --------------------------------------------------------------------------------
    > slacki schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Mal abgesehen davon, dass getter/setter absolut gegen OO verstossen
    >
    > Moment, waren es nicht Getter und Setter, die aufgrund der Datenkapselung
    > definitiv Teil von OOP sind?

    Je nachdem wie man das ganze auffasst.

    Ursprungsdefinition wie sie auch in Smalltalk umgesetzt wurde:
    “1. Everything is an object, 2. Objects communicate by sending and receiving messages (in terms of objects), 3. Objects have their own memory (in terms of objects), 4. Every object is an instance of a class (which must be an object), 5. The class holds the shared behavior for its instances (in the form of objects in a program list), 6. To eval a program list, control is passed to the first object and the remainder is treated as its message”

    Genauer spezifiziert wird es später in data abstraction und messaging. Anderen Objekte müssen Implementierungsdetails einer Klasse egal sein. Sie tauschen nur Nachrichten mit der Klasse aus. Datenkapselung sagt dabei vereinfacht, wie die Schnittstellen von und zu der Klasse implementiert sind.

    Getter und Setter sind ein dreckiger Weg zur Datenkapselung, welche einen Teil der Abstraktion verletzt.

    Nimm mal an, mit einem Feldtyp wird intern in einem Objekt gerechnet.
    du hast dein private int a... und dein int getA()...
    Am Anfang reicht ein int32 aus, später wird die Implementierung auf ein long geändert.
    Hast du also ein System, welches extrem stark auf Accessors und Setter/Getter aufbaut, verletzt es häufig genau die Abstraktion, da es interne Details preisgibt welche meist nicht nötig sind. Häufig wird aller möglicher Quatsch preisgegeben, da es einfacher ist dann in anderen Klassen etwas damit zu machen. Und da ist der Fehler. Bei gutem Objektorientierten Design müssen so gut wie keine Variablen über getter/setter getauscht werden, sondern man sagt dem Objekt das man etwas tun möchte und das Objekt arbeitet dies mit internen Variablen ab.

    Wenn jemand schreibt, dass er der ganz große Hecht ist weil ihm eine IDE ihm getter/setter abnimmt, dann macht er meist eine ganz dumme Sache: Er hat gehört public int a; ist schlecht und macht deswegen ein private int a; gefolgt von einem setA() und getA() die beide ausschließlich nur dem Zugriff auf die Variable dienen und hat sich praktisch ein public int a; nachgebaut. Eventuell mit späteren Nebeneffekten der setter/getter, aber eben ohne Nachdenken wie eine sinnvolle Klassenbeziehung und Schnittstelle aussieht. Sie brechen an der Stelle eben die Kapselung auf, für die manche denken dass sie verwendet werden können.

    Es gibt sinnvolle Anwendungen, man kann durchaus auch die Schnittstelle teilweise damit implementieren, aber häufig sind getter/setter nur fehlendes OO Design und daher ein code smell. Halt eine praktische schnelle Abkürzung.

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Bosch Gruppe, Stuttgart
  2. OEDIV KG, Bielefeld
  3. dc-ce rz-beratung GmbH & Co. KG, Frankfurt am Main
  4. Hornbach-Baumarkt-AG, Neustadt an der Weinstraße

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. 164,90€ + Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


IT-Jobs: Achtung! Agiler Coach gesucht?
IT-Jobs
Achtung! Agiler Coach gesucht?

Überall werden sie gesucht, um den digitalen Wandel voranzutreiben: agile Coaches. In den Jobbeschreibungen warten spannende Aufgaben, jedoch müssen Bewerber aufpassen, dass sie die richtigen Fragen stellen, wenn sie etwas bewegen möchten.
Von Marvin Engel

  1. Wework Die Kaffeeautomatisierung des Lebens
  2. IT-Jobs Fünf neue Mitarbeiter in fünf Wochen?
  3. Frauen in IT-Berufen Programmierte Klischees

Disenchantment angeschaut: Fantasy-Kurzweil vom Simpsons-Schöpfer
Disenchantment angeschaut
Fantasy-Kurzweil vom Simpsons-Schöpfer

Mit den Simpsons ist er selbst Kult geworden, und Nachfolger Futurama hat nicht nur Sci-Fi-Nerds mit einem Auge für verschlüsselte Gags im Bildhintergrund begeistert. Bei Netflix folgt nun Matt Groenings Cartoonserie Disenchantment, die uns trotz liebenswerter Hauptfiguren in Märchenkulissen allerdings nicht ganz zu verzaubern weiß.
Eine Rezension von Daniel Pook

  1. Promotion Netflix testet Werbung zwischen Serienepisoden
  2. Streaming Wachstum beim Pay-TV dank Netflix und Amazon
  3. Videostreaming Netflix soll am Fernseher übersichtlicher werden

Computacenter: So gewinnt ein IT-Unternehmen Mitarbeiterinnen
Computacenter
So gewinnt ein IT-Unternehmen Mitarbeiterinnen

Frauen hätten weniger Interesse an IT-Berufen als Männer und daran könne man nichts ändern, wird oft behauptet. Der IT-Dienstleister Computacenter hat andere Erfahrungen gemacht.
Ein Interview von Juliane Gringer

  1. Studitemps Einige Studierende verdienen in der IT unter Mindestlohn
  2. SAP-Berater Der coolste Job nach Tourismusmanager und Bierbrauer
  3. Digital Office Index 2018 Jeder zweite Beschäftigte sitzt am Computer

  1. CD Projekt Red: Strahlende Augen und scharfer Stahl in Cyberpunk 2077
    CD Projekt Red
    Strahlende Augen und scharfer Stahl in Cyberpunk 2077

    Gamescom 2018 Ballern oder friedlich vorgehen? In Köln hat CD Projekt Red neue Szenen aus Cyberpunk 2077 gezeigt und Golem.de hat mit einem Questdesigner über Unterschiede zu The Witcher 3 gesprochen.

  2. iTunes-Provision: Netflix will kein Geld mehr an Apple zahlen
    iTunes-Provision
    Netflix will kein Geld mehr an Apple zahlen

    Der Videostreamingdienst Netflix will offenbar nicht länger die Provisionen bezahlen, die bei der Abrechnung von Netflix-Abonnements an Apple fließen. In mehreren Ländern, darunter Deutschland, wird getestet, ob die Nutzer auch bereit sind, auf einer mobilen Website ihr Abo abzuschließen.

  3. Edelkamera: Leica M10-P mit Touchscreen, aber ohne den roten Punkt
    Edelkamera
    Leica M10-P mit Touchscreen, aber ohne den roten Punkt

    Leica hat mit der M10-P eine neue Messsucherkamera vorgestellt, die eine höherpreisige Variante der M10 darstellt. Leica hat den berühmten roten Punkt entfernt und einen leiseren Verschluss sowie einen Touchscreen eingebaut. Es soll sich bei der M10-P um die bisher leiseste M aller Zeiten handeln.


  1. 09:00

  2. 08:38

  3. 08:14

  4. 07:53

  5. 07:41

  6. 18:56

  7. 17:29

  8. 16:58