Byte-Welt Wiki - Benutzerbeiträge [de]

Log4J2 - Einfaches Konfigurationsfile

2014-10-05T14:37:17Z

Headnut:

Die Log4J2 Konfigurationsdatei speichert im Ordner logs drei Dateien (Infos.log, Warn.log, Error.log)

Aus dem Java Program kann nun in die einzelnen Levels geschrieben werden:

<code=java>log.info("Hello world - info log");</code=java>
<code=java>log.warn("Hello world - warn log");</code=java>
<code=java>log.erro("Hello world - error log");</code=java>

In der Console kommt jede Ausgabe, in den Logfiles nur die der entsprechenden Ebene:

<code=xml><?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<Appenders>


<Console name="STDOUT" target="SYSTEM_OUT">
<PatternLayout pattern="%d %-5p [%t] %C{2} (%F:%L) - %m%n" />
</Console>


<RollingFile name="fileInfo" fileName="logs/Info.log"
filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.info.gz">


<PatternLayout>
<pattern>%d %-5p [%t] %C{2} (%F:%L) - %m%n</pattern>
</PatternLayout>


<Filters>
<ThresholdFilter level="info" />
<ThresholdFilter level="warn" onMatch="DENY"
onMismatch="NEUTRAL" />
</Filters>


<Policies>
<SizeBasedTriggeringPolicy size="5 MB" />
</Policies>


<DefaultRolloverStrategy max="20" />
</RollingFile>


<RollingFile name="fileWarn" fileName="logs/Warn.log"
filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.warn.gz">


<PatternLayout>
<pattern>%d %-5p [%t] %C{2} (%F:%L) - %m%n</pattern>
</PatternLayout>


<Filters>
<ThresholdFilter level="warn" />
<ThresholdFilter level="error" onMatch="DENY"
onMismatch="NEUTRAL" />
</Filters>


<Policies>
<SizeBasedTriggeringPolicy size="5 MB" />
</Policies>


<DefaultRolloverStrategy max="20" />
</RollingFile>


<RollingFile name="fileError" fileName="logs/Error.log"
filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.error.gz">


<PatternLayout>
<pattern>%d %-5p [%t] %C{2} (%F:%L) - %m%n</pattern>
</PatternLayout>


<Filters>
<ThresholdFilter level="error" onMatch="ACCEPT"
onMismatch="DENY" />
</Filters>


<Policies>
<SizeBasedTriggeringPolicy size="5 MB" />
</Policies>


<DefaultRolloverStrategy max="20" />
</RollingFile>
</Appenders>

<Loggers>
<Logger name="org.apache.log4j2.xml">
<appender-ref ref="fileInfo" />
<appender-ref ref="fileWarn" />
<appender-ref ref="fileError" />
</Logger>

<Root level="info">
<AppenderRef ref="STDOUT" />
<AppenderRef ref="fileInfo" />
<AppenderRef ref="fileWarn" />
<AppenderRef ref="fileError" />
</Root>
</Loggers>
</Configuration>

</code=xml>

--[[Benutzer:headnut|headnut]] 16:36, 05. Okt 2014 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]

Log4J2 - Einfaches Konfigurationsfile

2014-10-05T14:35:56Z

Headnut:

Log4J2 - Einfaches Konfigurationsfile

2014-10-05T14:34:11Z

Headnut: Die Seite wurde neu angelegt: „Die Log4J2 Konfigurationsdatei speichert im Ordner logs drei Dateien (Infos.log, Warn.log, Error.log) Aus dem Java Program kann nun in die einzelnen Levels gesc…“

Die Log4J2 Konfigurationsdatei speichert im Ordner logs drei Dateien (Infos.log, Warn.log, Error.log)

Aus dem Java Program kann nun in die einzelnen Levels geschrieben werden:

[code=java]log.info("Hello world - info log");[/code]
[code=java]log.warn("Hello world - warn log");[/code]
[code=java]log.erro("Hello world - error log");[/code]

In der Console kommt jede Ausgabe, in den Logfiles nur die der entsprechenden Ebene:

[code=xml]<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<Appenders>


<Console name="STDOUT" target="SYSTEM_OUT">
<PatternLayout pattern="%d %-5p [%t] %C{2} (%F:%L) - %m%n" />
</Console>


<RollingFile name="fileInfo" fileName="logs/Info.log"
filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.info.gz">


<PatternLayout>
<pattern>%d %-5p [%t] %C{2} (%F:%L) - %m%n</pattern>
</PatternLayout>


<Filters>
<ThresholdFilter level="info" />
<ThresholdFilter level="warn" onMatch="DENY"
onMismatch="NEUTRAL" />
</Filters>


<Policies>
<SizeBasedTriggeringPolicy size="5 MB" />
</Policies>


<DefaultRolloverStrategy max="20" />
</RollingFile>


<RollingFile name="fileWarn" fileName="logs/Warn.log"
filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.warn.gz">


<PatternLayout>
<pattern>%d %-5p [%t] %C{2} (%F:%L) - %m%n</pattern>
</PatternLayout>


<Filters>
<ThresholdFilter level="warn" />
<ThresholdFilter level="error" onMatch="DENY"
onMismatch="NEUTRAL" />
</Filters>


<Policies>
<SizeBasedTriggeringPolicy size="5 MB" />
</Policies>


<DefaultRolloverStrategy max="20" />
</RollingFile>


<RollingFile name="fileError" fileName="logs/Error.log"
filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.error.gz">


<PatternLayout>
<pattern>%d %-5p [%t] %C{2} (%F:%L) - %m%n</pattern>
</PatternLayout>


<Filters>
<ThresholdFilter level="error" onMatch="ACCEPT"
onMismatch="DENY" />
</Filters>


<Policies>
<SizeBasedTriggeringPolicy size="5 MB" />
</Policies>


<DefaultRolloverStrategy max="20" />
</RollingFile>
</Appenders>

<Loggers>
<Logger name="org.apache.log4j2.xml">
<appender-ref ref="fileInfo" />
<appender-ref ref="fileWarn" />
<appender-ref ref="fileError" />
</Logger>

<Root level="info">
<AppenderRef ref="STDOUT" />
<AppenderRef ref="fileInfo" />
<AppenderRef ref="fileWarn" />
<AppenderRef ref="fileError" />
</Root>
</Loggers>
</Configuration>

[/code]

Dependency/Code Injection mit Google Guice!

2013-12-25T08:57:14Z

Headnut:

Den Anfang macht das Bean. Angefangen mit dem Interface

<code=java>
package guicedemo;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public interface Config {
public String getValue(String key);

public void setValue(String key, String value);
}
</code=java>

Hier die ConfigImpl:

<code=java>
package guicedemo;

import java.util.Map;
import java.util.HashMap;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class ConfingImpl implements Config {

private Map<String, String> prefs = new HashMap<String, String>();

public ConfingImpl() {
super();
}

public String getValue(String key) {
return this.prefs.get(key);
}

public void setValue(String key, String value) {
this.prefs.put(key, value);
}
}
</code=java>

ReadController:

<code=java>
package guicedemo;

import com.google.inject.Inject;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class ReadController
{

private Config conf;

@Inject
public ReadController(Config conf)
{
super();
this.conf = conf;
}

public void printConfig()
{
System.out.println("Konfiguration: Test=" + this.conf.getValue("Test"));
}
}
</code=java>

Wie man hier sieht, hat man hier mehr keinen leeren (oder Standard) Konstruktor sondern einen mit dem Bean als Namen. Desweiteren ist das <code=inline>@Inject</code=inline> sehr wichtig (ohne dem funktioniert der ganze Zauber auch nicht).

WriteController:

<code=java>
package guicedemo;

import com.google.inject.Inject;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class WriteController {

private Config conf;

@Inject
public WriteController(Config conf) {
super();
this.conf = conf;
}

public void doConfig() {
this.conf.setValue("Test", "42");
}

}
</code=java>

Auch hier hat man wieder einen '''Konstruktor''' mit dem Interface, sowie das <code=inline>'''@Inject'''</code=inline> nicht vergessen.

Bei Google Guice hat man '''keine XML Datei''', was angibt welches Interface wohingebunden wird. Stattdessen macht man das in einem '''Interface (Module)''' oder einer '''abstrakten Klasse (AbstractModule)'''.

Ich habe diese Konfiguration in meiner main Klasse gemacht. Indem sie von '''AbstractModule''' abgeleitet ist und die Methode '''configure''' überschreibt. Man könnte es auch über eine '''anonyme Klasse''' übergeben (so mache ich es im 2ten Bsp!).

<code=java>
package guicedemo;

import com.google.inject.AbstractModule;
import com.google.inject.Scopes;
import com.google.inject.Injector;
import com.google.inject.Guice;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class Main extends AbstractModule
{
public Main()
{
super();
}

@Override
protected void configure()
{
//hier wird es zugewiesen
bind(Config.class)
.to(ConfingImpl.class)
.in(Scopes.SINGLETON);
}

public static void main(String args[])
{
Injector injector = Guice.createInjector(new Main()); //holt den Injector
ReadController reader = injector.getInstance(ReadController.class); //instanziert die Klasse
reader.printConfig();
WriteController writer = injector.getInstance(WriteController.class); //nochmals die Klasse
writer.doConfig();
reader.printConfig();
}

}
</code=java>

Wie man sieht, MUSS man sich den Injector über eine statische Methode holen. Diesen gibt man ein '''Module''' oder ein '''AbstractModule''' an, welches ungefähr die gleiche Arbeit verrichtet, wie unter spring die XML Datei.
Es gibt an, worauf unsere Bean/Interface gebunden werden soll.

Ausgabe:
<code=inline>
Konfiguration: Test=null 
Konfiguration: Test=42
</code=inline>

Hier noch ein Bsp wie man 2 Beans konfigurieren kann.
Es ist '''nicht zwingend notwendig''', dass alle '''Klassen''' diese '''Beans''' im '''Konstruktor''' haben.

Hier das neue Interface:

<code=java>
package guicedemo;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public interface Demo {
public int getDemoWert();
}
</code=java>

Die Impl dazu:

<code=java>
package guicedemo;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class DemoImpl implements Demo {
private static int var = 0; // um zu sehen wie oft es instanziert wird

public DemoImpl() {
super();
var++;
}

public int getDemoWert() {
return var;
}
}
</code=java>

Der WriteController ist UNVERÄNDERT (also der Konstruktor hat weiterhin nur 1 Parameter).

Neuer ReadController:

<code=java>
package guicedemo;

import com.google.inject.Inject;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class ReadController {

private Config conf;
private Demo demo;

@Inject
public ReadController(Config conf, Demo demo) // zusätzlicher parameter
{
super();
this.conf = conf;
this.demo = demo;
}

public void printConfig() {
System.out.println("Konfiguration: Test=" + this.conf.getValue("Test") + " DEMO WERT: " + demo.getDemoWert());
}
}
</code=java>

Wie man sieht, hat man hier einen zusätzlichen Parameter, aber das stellt kein Problem dar.

Neue Main:

<code=java>
package guicedemo;

import com.google.inject.AbstractModule;
import com.google.inject.Scopes;
import com.google.inject.Injector;
import com.google.inject.Guice;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class Main {
public static void main(String args[]) {
// mit anonamyer Klasse instanzieren
Injector injector = Guice.createInjector(new AbstractModule() {
@Override
protected void configure() {
// hier wird es zugewiesen
bind(Config.class).to(ConfingImpl.class).in(Scopes.SINGLETON);
bind(Demo.class).to(DemoImpl.class).in(Scopes.SINGLETON);

}
});

ReadController reader = injector.getInstance(ReadController.class);
reader.printConfig();
WriteController writer = injector.getInstance(WriteController.class);
writer.doConfig();
reader.printConfig();
}

}
</code=java>

Habe den Injector auf eine anonyme Klasse umgebaut und die Ausgabe ist wiefolgt:

<code=inline>
Konfiguration: Test=null DEMO WERT: 1 
Konfiguration: Test=42 DEMO WERT: 1
</code=inline>

Wie man sieht, geht Code Injection mit Google Guice recht leicht.

Links:
[https://code.google.com/p/google-guice/ Google Guice]

--[[Benutzer:eRaaaa|thE_29 ]] 17:07, 24. Marz 2009 (CET)

[[Kategorie:Java]]
[[Kategorie:DI Google Guice]]

Dependency/Code Injection mit Google Guice!

2013-12-25T08:55:53Z

Headnut:

Dependency/Code Injection mit Google Guice!

2013-12-25T08:53:26Z

Headnut:

Den Anfang macht das Bean. Angefangen mit dem Interface

<code=java>
package guicedemo;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public interface Config {
public String getValue(String key);

public void setValue(String key, String value);
}
</code=java>

Hier die ConfigImpl:

<code=java>
package guicedemo;

import java.util.Map;
import java.util.HashMap;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class ConfingImpl implements Config {

private Map<String, String> prefs = new HashMap<String, String>();

public ConfingImpl() {
super();
}

public String getValue(String key) {
return this.prefs.get(key);
}

public void setValue(String key, String value) {
this.prefs.put(key, value);
}
}
</code=java>

ReadController:

<code=java>
package guicedemo;

import com.google.inject.Inject;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class ReadController
{

private Config conf;

@Inject
public ReadController(Config conf)
{
super();
this.conf = conf;
}

public void printConfig()
{
System.out.println("Konfiguration: Test=" + this.conf.getValue("Test"));
}
}
</code=java>

Wie man hier sieht, hat man hier mehr keinen leeren (oder Standard) Konstruktor sondern einen mit dem Bean als Namen. Desweiteren ist das <code=inline>@Inject</code=inline> sehr wichtig (ohne dem funktioniert der ganze Zauber auch nicht).

WriteController:

<code=java>
package guicedemo;

import com.google.inject.Inject;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class WriteController {

private Config conf;

@Inject
public WriteController(Config conf) {
super();
this.conf = conf;
}

public void doConfig() {
this.conf.setValue("Test", "42");
}

}
</code=java>

Auch hier hat man wieder einen '''Konstruktor''' mit dem Interface, sowie das <code=inline>'''@Inject'''</code=inline> nicht vergessen.

Bei Google Guice hat man '''keine XML Datei''', was angibt welches Interface wohingebunden wird. Stattdessen macht man das in einem '''Interface (Module)''' oder einer '''abstrakten Klasse (AbstractModule)'''.

Ich habe diese Konfiguration in meiner main Klasse gemacht. Indem sie von '''AbstractModule''' abgeleitet ist und die Methode '''configure''' überschreibt. Man könnte es auch über eine '''anonyme Klasse''' übergeben (so mache ich es im 2ten Bsp!).

<code=java>
package guicedemo;

import com.google.inject.AbstractModule;
import com.google.inject.Scopes;
import com.google.inject.Injector;
import com.google.inject.Guice;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class Main extends AbstractModule
{
public Main()
{
super();
}

@Override
protected void configure()
{
//hier wird es zugewiesen
bind(Config.class)
.to(ConfingImpl.class)
.in(Scopes.SINGLETON);
}

public static void main(String args[])
{
Injector injector = Guice.createInjector(new Main()); //holt den Injector
ReadController reader = injector.getInstance(ReadController.class); //instanziert die Klasse
reader.printConfig();
WriteController writer = injector.getInstance(WriteController.class); //nochmals die Klasse
writer.doConfig();
reader.printConfig();
}

}
</code=java>

Wie man sieht, MUSS man sich den Injector über eine statische Methode holen. Diesen gibt man ein '''Module''' oder ein '''AbstractModule''' an, welches ungefähr die gleiche Arbeit verrichtet, wie unter spring die XML Datei.
Es gibt an, worauf unsere Bean/Interface gebunden werden soll.

Ausgabe:
<code=inline>
Konfiguration: Test=null
Konfiguration: Test=42
</code=inline>

Hier noch ein Bsp wie man 2 Beans konfigurieren kann.
Es ist '''nicht zwingend notwendig''', dass alle '''Klassen''' diese '''Beans''' im '''Konstruktor''' haben.

Hier das neue Interface:

<code=java>
package guicedemo;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public interface Demo {
public int getDemoWert();
}
</code=java>

Die Impl dazu:

<code=java>
package guicedemo;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class DemoImpl implements Demo {
private static int var = 0; // um zu sehen wie oft es instanziert wird

public DemoImpl() {
super();
var++;
}

public int getDemoWert() {
return var;
}
}
</code=java>

Der WriteController ist UNVERÄNDERT (also der Konstruktor hat weiterhin nur 1 Parameter).

Neuer ReadController:

<code=java>
package guicedemo;

import com.google.inject.Inject;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class ReadController {

private Config conf;
private Demo demo;

@Inject
public ReadController(Config conf, Demo demo) // zusätzlicher parameter
{
super();
this.conf = conf;
this.demo = demo;
}

public void printConfig() {
System.out.println("Konfiguration: Test=" + this.conf.getValue("Test") + " DEMO WERT: " + demo.getDemoWert());
}
}
</code=java>

Wie man sieht, hat man hier einen zusätzlichen Parameter, aber das stellt kein Problem dar.

Neue Main:

<code=java>
package guicedemo;

import com.google.inject.AbstractModule;
import com.google.inject.Scopes;
import com.google.inject.Injector;
import com.google.inject.Guice;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class Main {
public static void main(String args[]) {
// mit anonamyer Klasse instanzieren
Injector injector = Guice.createInjector(new AbstractModule() {
@Override
protected void configure() {
// hier wird es zugewiesen
bind(Config.class).to(ConfingImpl.class).in(Scopes.SINGLETON);
bind(Demo.class).to(DemoImpl.class).in(Scopes.SINGLETON);

}
});

ReadController reader = injector.getInstance(ReadController.class);
reader.printConfig();
WriteController writer = injector.getInstance(WriteController.class);
writer.doConfig();
reader.printConfig();
}

}
</code=java>

Habe den Injector auf eine anonyme Klasse umgebaut und die Ausgabe ist wiefolgt:

<code=inline>
Konfiguration: Test=null DEMO WERT: 1
Konfiguration: Test=42 DEMO WERT: 1
</code=inline>

Wie man sieht, geht Code Injection mit Google Guice recht leicht.

Links:
[https://code.google.com/p/google-guice/ Google Guice]

Dependency/Code Injection mit Google Guice!

2013-12-25T08:45:11Z

Headnut:

Dependency/Code Injection mit Google Guice!

2013-12-25T08:37:44Z

Den Anfang macht das Bean. Angefangen mit dem Interface

[code=java]
package guicedemo;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public interface Config {
public String getValue(String key);

public void setValue(String key, String value);
}
[/code=java]

Hier die ConfigImpl:

[code=java]
package guicedemo;

import java.util.Map;
import java.util.HashMap;

/**
* Title:
*
* Description:
*
* Copyright: Copyright (c) 2009
*
* Company:
*
* @author Taschek Joerg
* @version 1.0
*/
public class ConfingImpl implements Config {

private Map<String, String> prefs = new HashMap<String, String>();

public ConfingImpl() {
super();
}

public String getValue(String key) {
return this.prefs.get(key);
}

public void setValue(String key, String value) {
this.prefs.put(key, value);
}
}
[/code=java]

Zugriffsmodifizierer (Java)

2013-09-17T11:12:41Z

Headnut:

== Zugriffsmodifizierer ==

{| {{Prettytable}}
! Modifizierer
! Die Klasse selbst
! Paket-Klassen/innere-Klassen
! Unterklassen
! Sonstige Klassen
|-
| private
| ja
| nein
| nein
| nein
|-
| public
| ja
| ja
| ja
| ja
|-
| protected
| ja
| ja
| ja
| nein
|-
| ohne/leer
| ja
| ja
| nein
| nein
|-
|}

== Modifizierer Übersicht ==

{| {{Prettytable}}
! Modifizierer
! Anwendbar auf
! Bedeutung
|-
| abstract
| - Klasse <br\>- Interface <br\>- Methode
| - Kann nicht instanziiert werden <br\>- Interfaces sind immer abstrakt (modifier optional)<br\> - Hat keinen Body, enthält nur Signatur. (die umschließende Klasse ist selbst auch abstrakt)
|-
| final
| - Klasse <br\>- Methode <br\>- Objektvariablen<br\>- Variablen
| - Kann nicht erweitert werden <br\> - Kann nicht überschrieben werden<br\>- Können ihren Wert nicht ändern <br\>- Können ihren Wert nicht ändern
|-
| nativ
| - Methode
| - Plattform spezifisch (keine Signatur, kein Body)
|-
| leer/keiner(package)
| - Klasse <br\>- Interface <br\>- Member
| - Nur im eigenen Paket sichtbar <br\>- Nur im eigenen Paket sichtbar <br\> - Nur im eigenen Paket sichtbar
|-
| private
| - Member
| - Nur in dieser Klasse sichtbar (wo sie definiert wurde)
|-
| protected
| - Member
| - Im eigenen package sichtbar und in Subklassen
|-
| public
| - Klasse <br\>- Interface <br\>- Member
| - Von überall aus sichtbar <br\> - Von überall aus sichtbar <br\> - Von überall aus da sichtbar, wo auch die Klasse sichtbar ist
|-
| strictfp
| - Klasse <br\>- Methode
| - Alle Methoden in der Klasse gehen strikt nach der IEEE-Norm vor <br\>- Methode geht strikt nach der IEEE-Norm vor
|-
| static
| - Klasse <br\>- Methode <br\>- Objektvariablen <br\> - Initialisierer
| - Macht eine innere Klase zu einer Top-Level-Klasse <br\> - Die Klassenmethode wird durch den Klassennamen aufgerufen <br\>- Zugriff über Klassennamen <br\> - Wird aufgerufen beim Laden der Klasse
|-
| synchronized
| - Methode
| - Bei statischen Methoden: lock für die dazugehörige Klasse, bei nicht-statischen methoden: lock für die jeweilige Objekt-Instanz
|-
| transient
| - Objektvariable
| - Wird nicht mit dem Objekt serialisiert
|-
| volatile
| - Objektvariable
| - Zugriffe auf diese Variablen sind atomar
|}

== Modifizierer: Alle Kombinationen ==

{| {{Prettytable}}
! Modifizierer
! Klasse
! Variable
! Methode
! Konstruktor
|-
| public
| ja
| ja
| ja
| ja
|-
| protected
| nein
| ja
| ja
| ja
|-
| keiner(package/default)
| ja
| ja
| ja
| ja
|-
| private
| nein
| ja
| ja
| nein
|-
| final
| ja
| ja
| ja
| nein
|-
| abstract
| ja
| nein
| ja
| nein
|-
| static
| nein
| ja
| ja
| nein
|-
| nativ
| nein
| nein
| ja
| nein
|-
| transient
| nein
| ja
| nein
| nein
|-
| volatile
| nein
| ja
| nein
| nein
|-
| synchronized
| nein
| nein
| ja
| nein
|-
| strictfp
| ja
| nein
| ja
| ja
|}

Quelle: <br\>
[http://www.javacamp.org/javaI/Modifier.html Java Modifiers] <br\>
[http://de.wikipedia.org/wiki/Java-Syntax Java-Syntax ? Wikipedia]

--[[Benutzer:eRaaaa|eRaaaa]] 13:08, 25. Dez 2009 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]

Zugriffsmodifizierer (Java)

2013-09-17T11:11:31Z

Headnut:

Zugriffsmodifizierer (Java)

2013-09-17T07:23:31Z

Headnut:

Zugriffsmodifizierer (Java)

2013-09-17T07:06:13Z

Headnut: Die Seite wurde neu angelegt: „Zugriffsmodifizierer“

Zugriffsmodifizierer

Was ist eine Exception?

2013-09-17T07:00:22Z

Headnut:

Eine Exception ist eine Ausnahmesituation, die normalerweise durch Fehler hervorgerufen wird. Diese Ausnahmen führen in der Regel zu einer Änderung des Programmablaufs, um etwa den Fehler zu beheben oder das Programm in einen sicheren
Zustand zu bringen.

[http://java.sun.com/docs/books/tutorial/essential/exceptions/ Lesson: Exceptions (The Java™ Tutorials > Essential Classes)]

== Was ist der Unterschied zwischen checked und unchecked Exceptions? ==

Unchecked Exceptions sind von der Klasse <code=intern>RuntimeException</code=intern> oder einer deren Unterklassen
abgeleitet. Sie müssen nicht explizit behandelt (mit catch gefangen) oder mit throws weitergeworfen werden.

Checked Exceptions sind nicht von <code=intern>RuntimeException</code=intern> abgeleitet. Kann eine Methode eine
checked Exception werfen, so muss sie entweder behandelt werden (try-catch) oder die
aufrufende Methode muss sie in der throws-Klausel deklarieren. D. h. die Exception wird weiter geworfen.

Die Begriffe ''Runtime-Exception'' und ''unchecked Exception'' können synonym verwendet werden.

<code=java>public void methodeMitRuntimeException() {
throw new NullPointerException(); // NullPointerException ist eine RuntimeException
}

public void methodeMitCheckedExceptionBehandelt() {
try {
foo(); // foo() kann IOException werfen. IOException ist eine checked Exception.
}
catch(IOException ex) {
//... Exception behandeln
}
}

public void methodeMitCheckedExceptionWeiterwerfen() throws IOException {
foo(); // foo() kann IOException werfen. IOException ist eine checked Exception.
}</code=java>

== Wie behandle ich eine Exception richtig? ==

Eine Exception sollte auf keinen Fall einfach verschluckt werden. Eine Fehlerausgabe, Logging der Exception oder ein Weiterwerfen sollten vorhanden sein.
Auch ist davon abzuraten, generell alle Exceptions in einem catch abzufangen. Es sollten immer nur konkrete Ausnahmen gefangen werden.
Dies verhindert, dass man "aus Versehen" eine Exception fängt, die gar nicht behandelt werden soll.

<code=java>public void foo() {
try {
methodeDieExceptionsWirft();
}
catch(Exception x) { // FALSCH! Nicht alle Exceptions auf einmal fangen!
// FALSCH! Exceptions nicht ignorieren!
}
}

public void bar() {
try {
methodeDieExceptionsWirft();
}
catch(FileNotFoundException fnfex) { // RICHTIG: konkrete Exceptions einzeln angeben
myExceptionHandler.handleException(x);
}
catch(SQLException sqlex) {
sqlex.printStacktrace(); // OK: Stacktrace auf Konsole ausgeben
LOGGER.error(sqlex); // BESSER: Exception loggen
}
catch(ParseException pex) {
throw new RuntimeException("unerwartete Exception", pex); // OK: checked Exception in RTEx kapseln
}
}</code=java>

== Wann soll ich Runtime-Exceptions und wann checked Exceptions verwenden? ==

Checked Exceptions zwingen den Aufrufer zur sofortigen Behandlung bzw. expliziten Weiterleitung
der Exception. Dies ist nur sinnvoll, wenn eine Chance besteht, die Ausnahmesituation zu
reparieren ("reasonably be expected to recover" [http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html [1]]). Andernfalls gibt es nur die Möglichkeit,
dem Anwender eine Fehlermeldung zu präsentieren, die Exception zu loggen oder die Anwendung
kontrolliert zu beenden. In solchen Fällen sind ungeprüfte Ausnahmen (Runtime-Exceptions) vorzuziehen.

[http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html Unchecked Exceptions — The Controversy (The Java™ Tutorials > Essential Classes > Exceptions)]

== Stimmt es, dass RuntimeExceptions immer auf Programmierfehler hindeuten und nie gefangen werden sollten? ==

Ursprünglich stimmte das, wenn man nur die vordefinierten Exception in der Java API betrachtet. Ausnahmen
wie NullPointerException, ArrayIndexOutOfBoundsException oder IllegalArgumentException deuten wirklich
auf Programmierfehler hin, die in funktionierenden Programmen nie auftreten sollten. Falls doch, sollte
der Bug behoben werden, statt die Exception zu behandeln.

Andererseits gehen Frameworks und Software-Bibliotheken mehr und mehr dazu über, nur noch unchecked Exceptions
zu benutzen. Diese sind in der Regel nicht durch Programmierfehler bedingt. So wirft das Persistenz-Framework
Hibernate eine Runtime-Exception, wenn beispielsweise die Datenbank nicht verfügbar ist.
Solche Ausnahmen können natürlich auch gefangen und behandelt werden, wenn dies möglich und sinnvoll ist.

Eine Gleichsetzung Runtime-Exceptions == Programmierfehler kann also nicht verallgemeinert werden.

== Was ist das Problem mit checked Exceptions? ==

Checked Exceptions sind nur dann sinnvoll, wenn bei ihrem Auftreten unmittelbar die Möglichkeit besteht, die
Ausnahmesituation zu beheben und dem Programmablauf normal fortzufahren.

'''- Checked Exceptions führen zu überflüssigem Code'''

In der Praxis sind Fälle, in denen man auf jeden Fall von einer Behebbarkeit ausgehen kann, jedoch sehr selten.
Trotzdem wird er Entwickler gezwungen, die Exception (unnötigerweise) zu behandeln, da sonst der Code
nicht kompilierbar ist. Da führt zu eigentlich überflüssigen try-catch-Anweisungen, die den Quelltext länger
und schwerer zu lesen machen. Im schlimmsten Fall wird die Exception einfach nur verschluckt.

'''- Behebbare Ausnahmen sind selten und oft nicht eindeutig zu identifizieren'''

Beispiel:
IOException auf der Java Standard-API ist eine checked Exception, sie muss also behandelt werden. In einigen
Anwendungsfällen ist dies natürlich möglich. Hat der Anwender beispielsweise einen falschen Dateinamen
eingetippt, so kann man den entsprechenden Eingabedialog erneut öffnen und den richtigen Dateinamen verlangen.
Diese Situation ist behebbar.
Was soll aber passieren, wenn IOException in einem Server-Prozess fliegt, etwa, weil die Konfigurationsdatei
der Servers nicht gelesen werden kann oder kein freier Festplattenspeicher mehr verfügbar ist. Diese
Situationen sind nicht behebbar. Es bleibt einem nichts anderes übrig, als die Exception zu loggen, ggf. den
Administrator zu verständigen und das Programm zu beenden.
IOException kann also nicht immer sinnvoll behandelt werden. Daraus folgt, dass sie eigentlich keine checked Exception
sein sollte, sondern eine Runtime-Exception.

Generell sollten Frameworks oder allgemein verwendbare Bibliotheken keine checked Exceptions verwenden. In abgeschlossenen
Software-Systemen (Individualsoftware) können geprüfte Ausnahmen manchmal sinnvoll sein.

'''- Checked Exceptions verschmutzen Interfaces und führen zu hoher Kopplung'''

Beispiel:
Das Service-Interface von Java RMI verlangt von jeder Methode, die checked Exception RemoteException in der
throws-Klausel zu deklarieren. Dadurch wird es hart an diese Technologie gekoppelt. Soll zum Beispiel
in Zukunft RMI durch ein anderes Remote-Procedure-Call Produkt ausgetauscht werden, sind umfangreiche
Änderungen am Quelltext notwendig, um überall die RemoteExceptions und die entsprechenden catch-Blöcke
zu entfernen.
Umgekehrt ist es noch schlimmer: Besteht bereits ein Service-Interface, das im Programm verwendet wird, und
soll es jetzt durch RMI implementiert werden, so muss man entsprechend throws RemoteException an allen
Methoden hinzufügen. An sämtlichen aufrufenden Stellen muss darüber hinaus die Exceptionbehandlung
ergänzt werden.

== Warum dann überhaupt checked Exceptions? ==

Gute Frage. Der Nutzen von checked Exceptions hat sich als sehr begrenzt heraus gestellt. Die
Nachteile durch das (gezwungene) Behandeln (mehr Quelltext, eventuell Verschlucken der Exception, siehe oben),
können Probleme verursachen. Es gibt einen Trend weg von checked Exceptions, z.B. werden in Hibernate
und Spring-Framework nur noch Runtime-Exceptions verwendet.
Das Konzept der checked Exceptions gibt es so nur in Java. In neueren, auch von Java inspirierten Sprachen
wie C# oder Groovy, wurde darauf verzichtet.

[http://www.javaspecialists.eu/archive/Issue033.html JavaSpecialists 033 - Making Exceptions Unchecked] <br\>
[http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html Java's checked exceptions were a mistake (and here's what I would like to do about it)]<br\>
[http://www.mindview.net/Etc/Discussions/CheckedExceptions Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions?]<br\>

== Was tun mit all den unbehandelten Exceptions? ==

Runtime-Exceptions die nicht mit catch gefangen und behandelt werden, nennt man uncaught Exceptions. Seit Java 1.5
hat man die Möglichkeit, für jeden Thread einen [http://java.sun.com/javase/6/docs/api/java/lang/Thread.UncaughtExceptionHandler.html UncaughtExceptionHandler] zu installieren. Darüber hinaus
gibt es einen globalen [http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler) Default-UncaughtExceptionHandler], der standardmäßig verwendet wird, falls kein Thread-spezifischer gesetzt wurde.
Hier kann zentral festgelegt werden, was mit solchen Ausnahmen geschehen soll, beispielsweise die Darstellung
eines Fehlerdialogs.

== Wieso heißt es RuntimeException? Alle Exceptions fliegen doch zur Laufzeit. ==

Das ist richtig. Ursprünglich unterschied man zwischen Exceptions, die explizit vom
Programmierer erzeugt und geworfen werden und solchen, die von
der Java Laufzeitumgebung (JRE), also der Virtuellen Maschine, implizit erzeugt werden.
Wenn zum Beispiel versucht wird, eine Null-Referenz zu dereferenzieren oder über
die Grenzen eines Arrays hinaus zuzugreifen, wirft die Java Laufzeitumgebung automatisch
eine entsprechende Exception. Daher der Name RuntimeException.

Rein praktisch können RuntimeException natürlich auch explizit vom Programmierer erzeugt und
geworfen werden, ganz genau wie geprüfte Ausnahmen.

== Was ist ein Error? ==

Ein Error ist auch eine Art Exception, die eine schwere Ausnahmesituation darstellt. Sie kann in der Regel nicht
behoben werden (z.B. OutOfMemoryError). Ähnlich wie RuntimeExceptions müssen Errors weder gefangen noch mit
der throws-Klausel deklariert werden.

== Was ist Throwable? ==

Throwable ist die Oberklasse für alle Exceptions, RuntimeExceptions und Errors - also alles, was geworfen werden kann.

--[[Benutzer:tfa|tfa]] 13:08, 30. Juli 2010 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]

Was ist eine Exception?

2013-09-17T06:57:08Z

Headnut: Die Seite wurde neu angelegt: „Eine Exception ist eine Ausnahmesituation, die normalerweise durch Fehler hervorgerufen wird. Diese Ausnahmen führen in der Regel zu einer Änderung des Programm…“

GroupLayout für Homosapiens

2013-09-02T17:20:14Z

Headnut: Die Seite wurde neu angelegt: „== GroupLayout für Homosapiens: == Das GroupLayout ist ein mächtiger LayoutManager, der leider oft als komplizierter missverstanden wird, als er eigentlich ist…“

== GroupLayout für Homosapiens: ==

Das GroupLayout ist ein mächtiger LayoutManager, der leider oft als komplizierter missverstanden wird, als er eigentlich ist. Besonders GUI-Builder erzeugen meist sehr hässlichen Code mit dem Grouplayout, weshalb ich euch rate erst mal ein GroupLayout von Hand zu schreiben.
GroupLayout wurde mit dem Ziel geschaffen, von GUI Buildern verwendet zu werden, von Hand programmiert, liegt der Schreibaufwand etwa wie beim GridBagLayout.

Einem JPanel ein GroupLayout zu verpassen funktioniert erstmal nicht ganz genauso wie bei anderen LayoutManagern:

<code=java>JPanel panel=new JPanel();
GroupLayout layout = new GroupLayout(panel);
panel.setLayout(layout);</code=java>

Vorsicht: Das GroupLayout wirft sehr schnell mal Exceptions wenn bei der initialisierung etwas schief gelaufen ist (z.B ein Komponent vergessen). Davon nicht abschrecken lassen! Andere LayoutManager kaschieren manche Ungereimtheiten und zeigen trotzdem was an. Das GroupLayout ist da wohl eher auf Perfektionismus ausgelegt: richtig oder gar nicht.

== Zu den Komponenten: ==

Auch hier geht das GroupLayout wieder einen eigenen Weg: Komponenten werden nicht per panel.add(Component c) "hinzugefügt".
Man fasst die Komponenten in Gruppen zusammen und setzt diese in Beziehungen zueinander.
Anders als bei den GridBagConstraints wurde beim GroupLayout dieses "Beziehungen setzen" aber zweigeteilt: Man gibt die Größenverhältnisse einmal vertikal und einmal horizontal an:

Beispiel: Wir imitieren ein FlowLayout mit 3 Labels:

<code=java>JLabel label1=new JLabel("1");
JLabel label2=new JLabel("2");
JLabel label3=new JLabel("3");</code=java>

=== 1. Beziehungen auf vertikaler Ebene: ===

Wir wollen, dass alle 3 Labels in der gleichen Zeile stehen. Sehen wir von "Norden" aus auf unser Layout drauf (man beuge sich über den Bildschirm und blicke nach unten), sind die 3 Labels nebeneinander. Wenn wir 2 oder mehr Komponenten nebeneinander ausrichten wollen, benötigen wir eine ParallelGroup:

<code=java>ParallelGroup verticalGroup=layout.createParallelGroup();</code=java>

Dieser ParallelGroup werden jetzt die Komponenten hinzugefügt:

<code=java>verticalGroup.addComponent(label1).addComponent(label2).addComponent(label3);</code=java>

=== 2. Beziehungen auf horizontaler Ebene: ===

Sehen wir von "Westen" auf unser Layout (man stelle sich links neben den Bildschirm und blicke hinein), sind die 3 Labels hintereinander. Dafür gibts die SequentialGroup:

<code=java>SequentialGroup horizontalGroup=layout.createSequentialGroup;

horizontalGroup.addComponent(label1).addComponent(label2).addComponent(label3);</code=java>

Zum Abschluss müssen wir unsere erstellten Gruppen noch dem Layout mit folgenden Methoden zuweisen:

<code=java>layout.setVerticalGroup(verticalGroup);
layout.setHorizontalGroup(horizontalGroup);</code=java>

Jetzt noch panel in einen JFrame packen und fertig, unser erstes GroupLayout läuft!

'''Wichtig:''' Wenn du einen Komponenten nur zu einer Group addest, fliegt eine Exception und es wird nichts angezeigt!

== VerticalFlowLayout ==

Wie siehts nun mit komplexeren Masken aus? Ich hab früher versucht aus zig verschiedenen, verschachtelten Panels jeweils mit eigenen einfachen LayoutManagern eine GUI zusammenzubasteln. Der Aufwand war enorm, die Übersichtlichkeit schrecklich, es war fehleranfällig und meist kam sowieso nicht das raus was gewollt war.
Mit dem GroupLayout kannst du dir das Panel verschachteln sparen, du verschachtelst die Groups.

Beispiel: Wir erweitern unser VerticalFlowGroupLayout: Da soll in jede Zeile noch zusätzlich ein Textfeld und ein Button rein:

=== 1. Vertikale Group: ===

Wir stellen uns wieder vor, wir blicken von oben in unser Layout rein. Jetzt gibt’s zwei Betrachtungsweisen: Haben wir 3 Zeilen hintereinander, in denen je ein Label, ein Textfeld und ein Button nebeneinander stehen oder haben wir 3 Spalten nebeneinander mit jeweils 3 Labels, Textfeldern und Buttons hintereinander?
Die Entscheidung bleibt dir überlassen, ich werde es hier anhand des „3 Zeilen“ Ansatzes demonstrieren:

<code=java>SequentialGroup verticalGroup=layout.createSequentialGroup();

verticalGroup.addGroup(layout.createParallelGroup()
.addComponent(label1).addComponent(textField1).addComponent(button1)
);
verticalGroup.addGroup(layout.createParallelGroup()
.addComponent(label2).addComponent(textField2).addComponent(button2)
);
verticalGroup.addGroup(layout.createParallelGroup()
.addComponent(label3).addComponent(textField3).addComponent(button3)
);</code=java>

=== 2. Horizontale Group ===

Analog zur Vertikalen Group: Haben wir 3 Zeilen nebeneinander in denen Label, Textfeld und Button hintereinander stehen oder haben wir 3 Spalten hintereinander, in denen untereinander je 3 Labels, Textfelder oder Buttons stehen?
W man sich beim Vertikalen Teil für die Zeilen Denkweise entschieden hat, ist es mMn sinnvoll dabei zu bleiben:

<code=java>ParallelGroup horizontalGroup=layout.createParallelGroup();

horizontalGroup.addGroup(layout.createSequentialGroup()
.addComponent(label1).addComponent(textField1).addComponent(button1)
);
horizontalGroup.addGroup(layout.createSequentialGroup()
.addComponent(label2).addComponent(textField2).addComponent(button2)
);
horizontalGroup.addGroup(layout.createSequentialGroup()
.addComponent(label3).addComponent(textField3).addComponent(button3)
);</code=java>

In meinem StandardFrame mit fixer Größe sieht das ganze nun aber so aus:

Die Komponenten füllen den gesamten Platz der aus – wir brauchen sowas wie einen Glue aus dem BoxLayout. Im GroupLayout heißt das Gap.

== Gaps und Größenangaben ==

Erstens gibt’s da mal eine Komfortfunktion die man ich eigentlich immer aktiviert habe:

<code=java>layout.setAutoCreateGaps(true);</code=java>

Damit kleben die Komponenten nicht mehr so aneinander, wie man das auch vom GridLayout her kennt.

Zu unserm Problem, wir können Gaps genauso wie Komponenten einer Gruppe hinzufügen:

<code=java>verticalGroup.addGap(Short.MAX_VALUE);</code=java>

addGap erwartet einen Integer Wert als Parameter, der angibt wie groß der Gap sein soll. Short.MAX_VALUE liegt bei ca. 32000, so große Displays gibt’s noch nicht.

Man kann addGap aber auch 3 ints übergeben: addGap(int min,int pref, int max)
Man kann also Minimum, Preferred und Maximum Size einstellen. Das funktioniert genauso bei Komponenten:

Ändern wir den Code auf

<code=java>verticalGroup.addGroup(layout.createParallelGroup()
.addComponent(label1)
. addComponent(textField1,20,20,20)
.addComponent(button1)
);</code=java>

Wird unser Textfield1 immer genau 20 Pixel hoch sein.
Achtung: Die Größenangaben beziehen sich immer auf die Achse, in der sie gemacht werden. Angaben in der VerticalGroup beeinflussen nur die Höhe, Angaben in der HorizontalGroup nur die Breite.

Die Größenangaben manuell anzugeben ist allerdings kein sauberer Stil. Komponenten haben ja selber schon min, preferred und max Size Einstellungen, die werden dadurch einfach ignoriert. Um dem GroupLayout zu sagen, es soll immer auf eine dieser Methoden zurückgreifen gibt’s 2 Konstanten:
GroupLayout.DEFAULT_SIZE und GroupLayout.PREFERRED_SIZE

<code=java>verticalGroup.addGroup(layout.createParallelGroup()
.addComponent(label1)
.addComponent(textField1,GroupLayout.DEFAULT_SIZE, GroupLayout.DEFAULT_SIZE,GroupLayout.PREFERRED_SIZE)
.addComponent(button1)
);</code=java>

Jetzt kann das Textfeld maximal die Höhe seiner PreferredSize haben.

Beispiel: Wir wollen links unten in unserem Fenster einen OK Button einfügen.

Wir fügen einen Gap zwischen Zeile 3 und dem Ok Button ein:

<code=java>verticalGroup.addGap(0,0,Short.MAX_VALUE);
verticalGroup.addComponent(okButton);

horizontalGroup.addGroup(layout.createSequentialGroup()
.addGap(0,0,Short.MAX_VALUE)
.addComponent(okButton));</code=java>

ein (0,0,Short.MAX_VALUE) Gap füllt soviel Platz aus, wie ihm zur Verfügung steht. Egal wie groß ihr das Fenster macht, der OK Button ist immer rechts unten.

== Fortgeschrittenes: ==

Beispiel: Wir stellen die Font eines unserer Labels auf 80 und wollen, dass die Textfeld und Button in der Mitte der Zeile angezeigt werden. Wir setzten für unsere Textfelder unterschiedliche Preferred Sizes und wollen dass die Buttons alle schön untereinander stehen und gleich breit sein. Ausserdem soll das Layout nur so viel Platz wie nötig ausfüllen.

Erstmal setzten wir ganz normal die Preferred Size der Textfelder und die Font des Labels:

<code=java>Font f = new Font( "Arial", Font.PLAIN, 80 );
label1.setFont(f);

textField1.setPreferredSize(new Dimension(70,20));
textField2.setPreferredSize(new Dimension(100,20));
textField3.setPreferredSize(new Dimension(130,20));</code=java>

'''Problem 1:''' Die Komponenten einer Zeile der Höhe nach mittig ausrichten:
ParallelGroups kann man beim erzeugen einen Alignment Parameter übergeben. (Alignment. LEADING, TRAILING, CENTER oder BASELINE

<code=java>verticalGroup.addGroup(layout.createParallelGroup(Alignment.CENTER)
.addComponent(label1)
.addComponent(textField1,GroupLayout.DEFAULT_SIZE,GroupLayout.DEFAULT_SIZE,GroupLayout.PREFERRED_SIZE)
.addComponent(button1)
);</code=java>

'''Problem 2:''' Quasi ein Tabstopp für die Buttons. Wir haben nicht mehr einfach 4 Zeilen, wir haben 4 Zeilen und 2 Spalten.

Die HorizontalGroup muss deshalb verändert werden:
Wir stellen uns vor, wir schauen von „Westen“/Links auf unser Layout.
Da wir in unserem Layout 2 Spalten haben (Rote Rechtecke), die klar abgegrenzt hintereinander kommen sollen Brauchen wir erstmal eine SequentialGroup.
SequentialGroup horizontalGroup=layout.createSequentialGroup();

Jetzt betrachten wir erstmal nur das linke Rechteck (um das rechte kümmern wir uns nachher).
3 Zeilen übereinander mit je Label und Textfeld hintereinander oder 3 Labels übereinander, danach 3 Textfelder übereinander. (Wir machens auf die Zeilen Art).

<code=java>ParallelGroup labelTextfieldGroup=layout.createParallelGroup()
.addGroup(layout.createSequentialGroup()
.addComponent(label1)
.addComponent(textField1,GroupLayout.DEFAULT_SIZE,GroupLayout.DEFAULT_SIZE,GroupLayout.PREFERRED_SIZE)
)
.addGroup(layout.createSequentialGroup()
.addComponent(label2)
.addComponent(textField2,GroupLayout.DEFAULT_SIZE,GroupLayout.DEFAULT_SIZE,GroupLayout.PREFERRED_SIZE)
)
.addGroup(layout.createSequentialGroup()
.addComponent(label3)
.addComponent(textField3,GroupLayout.DEFAULT_SIZE,GroupLayout.DEFAULT_SIZE,GroupLayout.PREFERRED_SIZE)
);</code=java>

Dann noch die 4 Buttons übereinander, das ist wieder einfacher:

<code=java>ParallelGroup buttonGroup=layout.createParallelGroup(Alignment.TRAILING)
.addComponent(button1)
.addComponent(button2)
.addComponent(button3)
.addComponent(okButton);</code=java>

Jetzt stöpseln wir die zwei roten Rechteck-Gruppen zusammen:

<code=java>horizontalGroup.addGroup(labelTextfieldGroup).addGroup(buttonGroup);</code=java>

'''Problem 3:''' Den Buttons die gleiche Breite verpassen.

Dafür gibt’s die Funktion linkSize:

<code=java>layout.linkSize(SwingConstants.HORIZONTAL,button1,button2,button3,okButton);</code=java>

SwingConstants.HORIZONTAL gibt an ob man die Breite oder die Höhe verlinken will. Danach kann man beliebig viele Komponenten hinzuschreiben (varargs).

== Weiterführende Links: ==

API-Dokumentation vom [http://docs.oracle.com/javase/7/docs/api/javax/swing/GroupLayout.html GroupLayout]
 
Oracle: [http://download.oracle.com/javase/tutorial/uiswing/layout/group.html How to Use GroupLayout (The Java™ Tutorials > Creating a GUI With JFC/Swing > Laying Out Components]

--[[Benutzer: bERt0r|bERt0r]] 04:06, 16. Dez 2011 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Swing]]

Java-Compiler-Level und .class-Datei Versionen (major- und minor version number)

2013-09-01T07:52:59Z

Headnut:

Der Compiler erzeugt vom JDK versionsabhängige Datei-Formate, die der Interpreter nach bestimmten Merkmalen untersucht, bevor er die Klasse ausführt.

Die Versionsnummern geben ihm Aufschluss darüber, ob eine Klasse mit einem kompatiblen JDK kompiliert wurde. Dazu vergleicht er u.a. die major- und die minor version number, welche neben der berühmten magic number (0xCAFEBABE) im Fileheader stehen.

Nachfolgend werden in einer Übersicht alle bisher veröffentlichten JDKs mit den dazu gehörenden major version und minor version numbers aufgelistet:

'''Eine Java-Anwendung, die mit einem aktuellen JDK kompiliert wurde, läuft nicht in einer älteren JRE.'''

== Compiler-Level ==

In den meisten Fällen genügt es bereits, den Compiler-Level auf die Zielplattform auszurichten und neu zu kompilieren.
Das heißt, dass mit einer Compiler-Option eingestellt werden kann, welche JRE-Version ein Programm mindestens benötigt, um ausgeführt zu werden.

Bsp: Eine Java-Anwendung wurde mit dem JDK 7 geschrieben. Beim Ausführen wird beim Anwender ein UnsupportedClassVersionError in der Java-Konsole ausgegeben.
Der Programmierer hat in seinem Programm nur Klassen aus den JDKs bis Version 6 verwendet. Dann kann er recht einfach die Anzahl der erreichbaren Ziel-VMs vergrößern, indem er den Compiler-Level auf Java 6 einstellt und neu kompiliert.
Die großen IDEs wie Eclipse und Netbeans bieten dazu Optionen in den Einstellungen an. Für Java-Editoren muss meist die Option an den Compiler-Aufruf angehängt werden.

<code=java>javac -source 1.6 -target 1.6 MeineKlasse.java</code=java>

Mit dieser Anweisung akzeptiert der Compiler nur Klassen, die bis zum JDK 6 eingeführt wurden und erzeugt Bytecode für JREs ab Version 6.

--[[Benutzer:L-ectron-X|L-ectron-X]] 09:50, 01. Sept 2013 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]

Java-Compiler-Level und .class-Datei Versionen (major- und minor version number)

2013-09-01T07:52:12Z

Headnut:

Der Compiler erzeugt vom JDK versionsabhängige Datei-Formate, die der Interpreter nach bestimmten Merkmalen untersucht, bevor er die Klasse ausführt.

Die Versionsnummern geben ihm Aufschluss darüber, ob eine Klasse mit einem kompatiblen JDK kompiliert wurde. Dazu vergleicht er u.a. die major- und die minor version number, welche neben der berühmten magic number (0xCAFEBABE) im Fileheader stehen.

Nachfolgend werden in einer Übersicht alle bisher veröffentlichten JDKs mit den dazu gehörenden major version und minor version numbers aufgelistet:

'''Eine Java-Anwendung, die mit einem aktuellen JDK kompiliert wurde, läuft nicht in einer älteren JRE.'''

== Compiler-Level ==

In den meisten Fällen genügt es bereits, den Compiler-Level auf die Zielplattform auszurichten und neu zu kompilieren.
Das heißt, dass mit einer Compiler-Option eingestellt werden kann, welche JRE-Version ein Programm mindestens benötigt, um ausgeführt zu werden.

Bsp: Eine Java-Anwendung wurde mit dem JDK 7 geschrieben. Beim Ausführen wird beim Anwender ein UnsupportedClassVersionError in der Java-Konsole ausgegeben.
Der Programmierer hat in seinem Programm nur Klassen aus den JDKs bis Version 6 verwendet. Dann kann er recht einfach die Anzahl der erreichbaren Ziel-VMs vergrößern, indem er den Compiler-Level auf Java 6 einstellt und neu kompiliert.
Die großen IDEs wie Eclipse und Netbeans bieten dazu Optionen in den Einstellungen an. Für Java-Editoren muss meist die Option an den Compiler-Aufruf angehängt werden.

<code=java>javac -source 1.6 -target 1.6 MeineKlasse.java<\code>

Mit dieser Anweisung akzeptiert der Compiler nur Klassen, die bis zum JDK 6 eingeführt wurden und erzeugt Bytecode für JREs ab Version 6.

--[[Benutzer:L-ectron-X|L-ectron-X]] 09:50, 01. Sept 2013 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]

Java-Compiler-Level und .class-Datei Versionen (major- und minor version number)

2013-09-01T07:51:35Z

Headnut:

Der Compiler erzeugt vom JDK versionsabhängige Datei-Formate, die der Interpreter nach bestimmten Merkmalen untersucht, bevor er die Klasse ausführt.

Die Versionsnummern geben ihm Aufschluss darüber, ob eine Klasse mit einem kompatiblen JDK kompiliert wurde. Dazu vergleicht er u.a. die major- und die minor version number, welche neben der berühmten magic number (0xCAFEBABE) im Fileheader stehen.

Nachfolgend werden in einer Übersicht alle bisher veröffentlichten JDKs mit den dazu gehörenden major version und minor version numbers aufgelistet:

'''Eine Java-Anwendung, die mit einem aktuellen JDK kompiliert wurde, läuft nicht in einer älteren JRE.'''

== Compiler-Level ==

In den meisten Fällen genügt es bereits, den Compiler-Level auf die Zielplattform auszurichten und neu zu kompilieren.
Das heißt, dass mit einer Compiler-Option eingestellt werden kann, welche JRE-Version ein Programm mindestens benötigt, um ausgeführt zu werden.

Bsp: Eine Java-Anwendung wurde mit dem JDK 7 geschrieben. Beim Ausführen wird beim Anwender ein UnsupportedClassVersionError in der Java-Konsole ausgegeben.
Der Programmierer hat in seinem Programm nur Klassen aus den JDKs bis Version 6 verwendet. Dann kann er recht einfach die Anzahl der erreichbaren Ziel-VMs vergrößern, indem er den Compiler-Level auf Java 6 einstellt und neu kompiliert.
Die großen IDEs wie Eclipse und Netbeans bieten dazu Optionen in den Einstellungen an. Für Java-Editoren muss meist die Option an den Compiler-Aufruf angehängt werden.

<code=java>javac -source 1.6 -target 1.6 MeineKlasse.java<code=java>

Mit dieser Anweisung akzeptiert der Compiler nur Klassen, die bis zum JDK 6 eingeführt wurden und erzeugt Bytecode für JREs ab Version 6.

--[[Benutzer:L-ectron-X|L-ectron-X]] 09:50, 01. Sept 2013 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]

Java-Compiler-Level und .class-Datei Versionen (major- und minor version number)

2013-09-01T07:51:14Z

Headnut:

Der Compiler erzeugt vom JDK versionsabhängige Datei-Formate, die der Interpreter nach bestimmten Merkmalen untersucht, bevor er die Klasse ausführt.

Die Versionsnummern geben ihm Aufschluss darüber, ob eine Klasse mit einem kompatiblen JDK kompiliert wurde. Dazu vergleicht er u.a. die major- und die minor version number, welche neben der berühmten magic number (0xCAFEBABE) im Fileheader stehen.

Nachfolgend werden in einer Übersicht alle bisher veröffentlichten JDKs mit den dazu gehörenden major version und minor version numbers aufgelistet:

'''Eine Java-Anwendung, die mit einem aktuellen JDK kompiliert wurde, läuft nicht in einer älteren JRE.'''

== Compiler-Level ==

In den meisten Fällen genügt es bereits, den Compiler-Level auf die Zielplattform auszurichten und neu zu kompilieren.
Das heißt, dass mit einer Compiler-Option eingestellt werden kann, welche JRE-Version ein Programm mindestens benötigt, um ausgeführt zu werden.

Bsp: Eine Java-Anwendung wurde mit dem JDK 7 geschrieben. Beim Ausführen wird beim Anwender ein UnsupportedClassVersionError in der Java-Konsole ausgegeben.
Der Programmierer hat in seinem Programm nur Klassen aus den JDKs bis Version 6 verwendet. Dann kann er recht einfach die Anzahl der erreichbaren Ziel-VMs vergrößern, indem er den Compiler-Level auf Java 6 einstellt und neu kompiliert.
Die großen IDEs wie Eclipse und Netbeans bieten dazu Optionen in den Einstellungen an. Für Java-Editoren muss meist die Option an den Compiler-Aufruf angehängt werden.

javac -source 1.6 -target 1.6 MeineKlasse.java

Mit dieser Anweisung akzeptiert der Compiler nur Klassen, die bis zum JDK 6 eingeführt wurden und erzeugt Bytecode für JREs ab Version 6.

--[[Benutzer:L-ectron-X|L-ectron-X]] 09:50, 01. Sept 2013 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Grundlagen]]

Java-Compiler-Level und .class-Datei Versionen (major- und minor version number)

2013-09-01T07:50:00Z

Headnut: Die Seite wurde neu angelegt: „Der Compiler erzeugt vom JDK versionsabhängige Datei-Formate, die der Interpreter nach bestimmten Merkmalen untersucht, bevor er die Klasse ausführt. Die Versi…“

Der Compiler erzeugt vom JDK versionsabhängige Datei-Formate, die der Interpreter nach bestimmten Merkmalen untersucht, bevor er die Klasse ausführt.

Die Versionsnummern geben ihm Aufschluss darüber, ob eine Klasse mit einem kompatiblen JDK kompiliert wurde. Dazu vergleicht er u.a. die major- und die minor version number, welche neben der berühmten magic number (0xCAFEBABE) im Fileheader stehen.

Nachfolgend werden in einer Übersicht alle bisher veröffentlichten JDKs mit den dazu gehörenden major version und minor version numbers aufgelistet:

'''Eine Java-Anwendung, die mit einem aktuellen JDK kompiliert wurde, läuft nicht in einer älteren JRE.'''

== Compiler-Level ==

In den meisten Fällen genügt es bereits, den Compiler-Level auf die Zielplattform auszurichten und neu zu kompilieren.
Das heißt, dass mit einer Compiler-Option eingestellt werden kann, welche JRE-Version ein Programm mindestens benötigt, um ausgeführt zu werden.

Bsp: Eine Java-Anwendung wurde mit dem JDK 7 geschrieben. Beim Ausführen wird beim Anwender ein UnsupportedClassVersionError in der Java-Konsole ausgegeben.
Der Programmierer hat in seinem Programm nur Klassen aus den JDKs bis Version 6 verwendet. Dann kann er recht einfach die Anzahl der erreichbaren Ziel-VMs vergrößern, indem er den Compiler-Level auf Java 6 einstellt und neu kompiliert.
Die großen IDEs wie Eclipse und Netbeans bieten dazu Optionen in den Einstellungen an. Für Java-Editoren muss meist die Option an den Compiler-Aufruf angehängt werden.

javac -source 1.6 -target 1.6 MeineKlasse.java

Mit dieser Anweisung akzeptiert der Compiler nur Klassen, die bis zum JDK 6 eingeführt wurden und erzeugt Bytecode für JREs ab Version 6.

Warum man nicht von JFrame/JDialog erben sollte

2013-08-29T14:08:20Z

Headnut:

== Warum man nicht von JFrame/JDialog erben sollte ==

Dieser Beitrag wurde von '''Firephoenix''' erstellt

Es ist doch verwunderlich wie oft man so etwas hier sieht:

<code=java>public class Gui extends JFrame{

public Gui(){
super("Toller titel");
setDefaultCloseOperation(EXIT_ON_CLOSE);
getContentPane().add(new JButton("sinnloser button"));
pack();
setVisible(true);
}
}</code=java>

Sieht irgendwie bekannt aus, oder?
Und: Normalerweise würgt man die VM auch nicht mit <code=java>System.exit(0);</code=java> respektive <code=java>frame.setDefaultCloseOperation(EXIT_ON_CLOSE);</code=java> ab, sondern ruft <code=java>dispose()</code=java> auf.

Tatsächlich ist der Code genauso furchtbar wie das hier:

<code=java>public class Buchregal extends ArrayList<String>{

public Buchregal(){
add("Spiele programmieren mit Java");
add("Spring im Einsatz");
add("Handbuch der Java Programmierung");
}
}</code=java>

Und mal ehrlich, wer würde auf die Idee kommen, so etwas anzustellen?

Da schreibt man ein Buchregal, das 3 Buchtitel enthält, doch lieber so oder?
(zugegeben es ist kein schönes Buchregal das nur die Titel kennt)

<code=java>public class Buchregal{

private ArrayList<String> buchtitel;

public Buchregal(){
buchtitel = new ArrayList<String>();
buchtitel.add("Spiele programmieren mit Java");
buchtitel.add("Spring im Einsatz");
buchtitel.add("Handbuch der Java Programmierung");
}
}</code=java>

Und genau so kann man auch mit der GUI-Klasse verfahren:

<code=java>public class Gui{

private JFrame frame;

public Gui(){
frame = new JFrame("Toller titel");
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.getContentPane().add(new JButton("sinnloser button"));
frame.pack();
frame.setVisible(true);
}
}</code=java>

Nur was hat man jetzt eigentlich gemacht?

In den ersten 2 Beispielen haben wir Vererbung benutzt, um eine Klasse zu verwenden.
Das Stichwort hier ist "verwenden" und nicht "erweitern"!
Wir haben lediglich bestehende Funktionen der Klasse JFrame verwendet, aber keine neue Funktionalität hinzugefügt.
Solange wir das nicht machen, besteht kein Grund von einer Klasse zu erben!

'''Verwenden != Erweitern'''

<blockquote L-ectron-X>
Wenn wir von einer Klasse erben, sprechen wir auch davon, sie zu spezialisieren.
Genauso, wie der Vater persönliche Eigenschaften an den Sohn vererbt, bekommt in der OOP eine erbende Klasse die Eigenschaften (Methoden und öffentliche Instanzvariablen) der Basisklasse (auch Superklasse) eingepflanzt. Die erbende Klasse muss aber für eine sinnvolle Anwendung der Vererbung weitere Eigenschaften erhalten, und/oder bestehende Eigenschaften spezialisieren.
Genauso wie der Sohn vom Vater die Fähigkeit erbte, besonders schnell die 60m zu laufen, kann der Sohn nun aber auch noch die 100m besonders schnell laufen. Eine Fähigkeit, zu der der Vater nicht im Stande ist.</blockquote>

Wie es im Englischen schön heißt: composition over inheritance.

Wir benutzen daher möglichst Felder anstatt Vererbung.

Felder können jederzeit ausgetauscht werden, unser Bücherregal könnte zur Programmlaufzeit die ArrayList durch eine LinkedList ersetzen, (oder wenn der typ des Feldes nur Collection <String> wäre), sogar auf ein HashSet umsteigen.
Benutzen wir dagegen Vererbung sind wir für alle Ewigkeit an die ArrayList gebunden und können zur Laufzeit nicht mehr davon weg.
Außerdem wird die Vererbung Teil der API unserer Software, ein anderer Programmierer wird unsere Komponente z.B. auch wie eine ArrayList verwenden, auch hier haben wir keine Möglichkeit etwas zu Ändern ohne anderen Code zu gefährden.
Halten wir dagegen solche Implementierungsdetails in privaten Feldern versteckt können wir zu jeder Zeit daran herumspielen, ohne das jemand etwas davon mitbekommen wird.

Ein Fall wo es tatsächlich Sinn macht von einer Grafikkomponente zu erben wäre dieser hier:

<code=java>public class PaintingPanel extends JPanel{

@Override
public void paintComponent(Graphics g){
super.paintComponent(g);
g.drawLine(3, 3, 6, 6);
}

} </code=java>

Hier haben wir das JPanel tatsächlich erweitert, nämlich um eine hässliche kleine Linie die darauf gezeichnet wird

Zu bemerken ist hier das @Override und der super-Aufruf.
Es ist kein guter Stil, Methoden komplett zu überschreiben (z.B. würde das hier zu Zeichenfehlern im eigentlichen Panel führen), daher rufen wir zuerst die Methode der Superklasse auf.
Weiterhin zeigt uns das @Override an, dass wir eine Methode der Superklasse überschrieben haben (und der Compiler meckert uns an wenn, wir sie falsch geschrieben haben -> gängige Fehlerquelle vermieden).

Generell also: 
'''Wenn wir eine Klasse verwenden wollen, legen wir ein Feld mit dem Typ der Klasse an und verwenden das Feld.'''

'''Wenn wir eine bestehende Klasse um neue Funktionalität erweitern wollen, dann erben wir von der Klasse.'''

composition over inheritance

--[[Benutzer:Firephoenix|Firephoenix]] 19:18, 28. Aug 2013 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Swing]]

Warum man nicht von JFrame/JDialog erben sollte

2013-08-28T17:19:49Z

Headnut:

== Warum man nicht von JFrame/JDialog erben sollte ==

Dieser Beitrag wurde von '''Firephoenix''' erstellt

Es ist doch verwunderlich wie oft man so etwas hier sieht:

<code=java>public class Gui extends JFrame{

public Gui(){
super("Toller titel");
setDefaultCloseOperation(EXIT_ON_CLOSE);
getContentPane().add(new JButton("sinnloser button"));
pack();
setVisible(true);
}
}</code=java>

Sieht irgendwie bekannt aus, oder?
Und: Normalerweise würgt man die VM auch nicht mit <code=java>System.exit(0);</code=java> respektive <code=java>frame.setDefaultCloseOperation(EXIT_ON_CLOSE);</code=java> ab, sondern ruft <code=java>dispose()</code=java> auf.

Tatsächlich ist der Code genauso furchtbar wie das hier:

<code=java>public class Buchregal extends ArrayList<String>{

public Buchregal(){
add("Spiele programmieren mit Java");
add("Spring im Einsatz");
add("Handbuch der Java Programmierung");
}
}</code=java>

Und mal ehrlich, wer würde auf die Idee kommen, so etwas anzustellen?

Da schreibt man ein Buchregal, das 3 Buchtitel enthält, doch lieber so oder?
(zugegeben es ist kein schönes Buchregal das nur die Titel kennt)

<code=java>public class Buchregal{

private ArrayList<String> buchtitel;

public Buchregal(){
buchtitel = new ArrayList<String>();
buchtitel.add("Spiele programmieren mit Java");
buchtitel.add("Spring im Einsatz");
buchtitel.add("Handbuch der Java Programmierung");
}
}</code=java>

Und genau so kann man auch mit der GUI-Klasse verfahren:

<code=java>public class Gui{

private JFrame frame;

public Gui(){
frame = new JFrame("Toller titel");
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.getContentPane().add(new JButton("sinnloser button"));
frame.pack();
frame.setVisible(true);
}
}</code=java>

Nur was hat man jetzt eigentlich gemacht?

In den ersten 2 Beispielen haben wir Vererbung benutzt, um eine Klasse zu verwenden.
Das Stichwort hier ist "verwenden" und nicht "erweitern"!
Wir haben lediglich bestehende Funktionen der Klasse JFrame verwendet, aber keine neue Funktionalität hinzugefügt.
Solange wir das nicht machen, besteht kein Grund von einer Klasse zu erben!

'''Verwenden != Erweitern'''

{{Zitat
| Autor = L-ectron-X
| Text = Wenn wir von einer Klasse erben, sprechen wir auch davon, sie zu spezialisieren.
Genauso, wie der Vater persönliche Eigenschaften an den Sohn vererbt, bekommt in der OOP eine erbende Klasse die Eigenschaften (Methoden und öffentliche Instanzvariablen) der Basisklasse (auch Superklasse) eingepflanzt. Die erbende Klasse muss aber für eine sinnvolle Anwendung der Vererbung weitere Eigenschaften erhalten, und/oder bestehende Eigenschaften spezialisieren.
Genauso wie der Sohn vom Vater die Fähigkeit erbte, besonders schnell die 60m zu laufen, kann der Sohn nun aber auch noch die 100m besonders schnell laufen. Eine Fähigkeit, zu der der Vater nicht im Stande ist.
}}

Wie es im Englischen schön heißt: composition over inheritance.

Wir benutzen daher möglichst Felder anstatt Vererbung.

Felder können jederzeit ausgetauscht werden, unser Bücherregal könnte zur Programmlaufzeit die ArrayList durch eine LinkedList ersetzen, (oder wenn der typ des Feldes nur Collection <String> wäre), sogar auf ein HashSet umsteigen.
Benutzen wir dagegen Vererbung sind wir für alle Ewigkeit an die ArrayList gebunden und können zur Laufzeit nicht mehr davon weg.
Außerdem wird die Vererbung Teil der API unserer Software, ein anderer Programmierer wird unsere Komponente z.B. auch wie eine ArrayList verwenden, auch hier haben wir keine Möglichkeit etwas zu Ändern ohne anderen Code zu gefährden.
Halten wir dagegen solche Implementierungsdetails in privaten Feldern versteckt können wir zu jeder Zeit daran herumspielen, ohne das jemand etwas davon mitbekommen wird.

Ein Fall wo es tatsächlich Sinn macht von einer Grafikkomponente zu erben wäre dieser hier:

<code=java>public class PaintingPanel extends JPanel{

@Override
public void paintComponent(Graphics g){
super.paintComponent(g);
g.drawLine(3, 3, 6, 6);
}

} </code=java>

Hier haben wir das JPanel tatsächlich erweitert, nämlich um eine hässliche kleine Linie die darauf gezeichnet wird

Zu bemerken ist hier das @Override und der super-Aufruf.
Es ist kein guter Stil, Methoden komplett zu überschreiben (z.B. würde das hier zu Zeichenfehlern im eigentlichen Panel führen), daher rufen wir zuerst die Methode der Superklasse auf.
Weiterhin zeigt uns das @Override an, dass wir eine Methode der Superklasse überschrieben haben (und der Compiler meckert uns an wenn, wir sie falsch geschrieben haben -> gängige Fehlerquelle vermieden).

Generell also: 
'''Wenn wir eine Klasse verwenden wollen, legen wir ein Feld mit dem Typ der Klasse an und verwenden das Feld.'''

'''Wenn wir eine bestehende Klasse um neue Funktionalität erweitern wollen, dann erben wir von der Klasse.'''

composition over inheritance

--[[Benutzer:Firephoenix|Firephoenix]] 19:18, 28. Aug 2013 (CET)

[[Kategorie:Java]]
[[Kategorie:Java Swing]]

Warum man nicht von JFrame/JDialog erben sollte

2013-08-28T17:18:48Z

Headnut:

== Warum man nicht von JFrame/JDialog erben sollte ==

Dieser Beitrag wurde von '''Firephoenix''' erstellt

Es ist doch verwunderlich wie oft man so etwas hier sieht:

<code=java>public class Gui extends JFrame{

public Gui(){
super("Toller titel");
setDefaultCloseOperation(EXIT_ON_CLOSE);
getContentPane().add(new JButton("sinnloser button"));
pack();
setVisible(true);
}
}</code=java>

Sieht irgendwie bekannt aus, oder?
Und: Normalerweise würgt man die VM auch nicht mit <code=java>System.exit(0);</code=java> respektive <code=java>frame.setDefaultCloseOperation(EXIT_ON_CLOSE);</code=java> ab, sondern ruft <code=java>dispose()</code=java> auf.

Tatsächlich ist der Code genauso furchtbar wie das hier:

<code=java>public class Buchregal extends ArrayList<String>{

public Buchregal(){
add("Spiele programmieren mit Java");
add("Spring im Einsatz");
add("Handbuch der Java Programmierung");
}
}</code=java>

Und mal ehrlich, wer würde auf die Idee kommen, so etwas anzustellen?

Da schreibt man ein Buchregal, das 3 Buchtitel enthält, doch lieber so oder?
(zugegeben es ist kein schönes Buchregal das nur die Titel kennt)

<code=java>public class Buchregal{

private ArrayList<String> buchtitel;

public Buchregal(){
buchtitel = new ArrayList<String>();
buchtitel.add("Spiele programmieren mit Java");
buchtitel.add("Spring im Einsatz");
buchtitel.add("Handbuch der Java Programmierung");
}
}</code=java>

Und genau so kann man auch mit der GUI-Klasse verfahren:

<code=java>public class Gui{

private JFrame frame;

public Gui(){
frame = new JFrame("Toller titel");
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.getContentPane().add(new JButton("sinnloser button"));
frame.pack();
frame.setVisible(true);
}
}</code=java>

Nur was hat man jetzt eigentlich gemacht?

In den ersten 2 Beispielen haben wir Vererbung benutzt, um eine Klasse zu verwenden.
Das Stichwort hier ist "verwenden" und nicht "erweitern"!
Wir haben lediglich bestehende Funktionen der Klasse JFrame verwendet, aber keine neue Funktionalität hinzugefügt.
Solange wir das nicht machen, besteht kein Grund von einer Klasse zu erben!

'''Verwenden != Erweitern'''

{{Zitat
| Autor = L-ectron-X
| Text = Wenn wir von einer Klasse erben, sprechen wir auch davon, sie zu spezialisieren.
Genauso, wie der Vater persönliche Eigenschaften an den Sohn vererbt, bekommt in der OOP eine erbende Klasse die Eigenschaften (Methoden und öffentliche Instanzvariablen) der Basisklasse (auch Superklasse) eingepflanzt. Die erbende Klasse muss aber für eine sinnvolle Anwendung der Vererbung weitere Eigenschaften erhalten, und/oder bestehende Eigenschaften spezialisieren.
Genauso wie der Sohn vom Vater die Fähigkeit erbte, besonders schnell die 60m zu laufen, kann der Sohn nun aber auch noch die 100m besonders schnell laufen. Eine Fähigkeit, zu der der Vater nicht im Stande ist.
}}

Wie es im Englischen schön heißt: composition over inheritance.

Wir benutzen daher möglichst Felder anstatt Vererbung.

Felder können jederzeit ausgetauscht werden, unser Bücherregal könnte zur Programmlaufzeit die ArrayList durch eine LinkedList ersetzen, (oder wenn der typ des Feldes nur Collection <String> wäre), sogar auf ein HashSet umsteigen.
Benutzen wir dagegen Vererbung sind wir für alle Ewigkeit an die ArrayList gebunden und können zur Laufzeit nicht mehr davon weg.
Außerdem wird die Vererbung Teil der API unserer Software, ein anderer Programmierer wird unsere Komponente z.B. auch wie eine ArrayList verwenden, auch hier haben wir keine Möglichkeit etwas zu Ändern ohne anderen Code zu gefährden.
Halten wir dagegen solche Implementierungsdetails in privaten Feldern versteckt können wir zu jeder Zeit daran herumspielen, ohne das jemand etwas davon mitbekommen wird.

Ein Fall wo es tatsächlich Sinn macht von einer Grafikkomponente zu erben wäre dieser hier:

<code=java>public class PaintingPanel extends JPanel{

@Override
public void paintComponent(Graphics g){
super.paintComponent(g);
g.drawLine(3, 3, 6, 6);
}

} </code=java>

Hier haben wir das JPanel tatsächlich erweitert, nämlich um eine hässliche kleine Linie die darauf gezeichnet wird

Zu bemerken ist hier das @Override und der super-Aufruf.
Es ist kein guter Stil, Methoden komplett zu überschreiben (z.B. würde das hier zu Zeichenfehlern im eigentlichen Panel führen), daher rufen wir zuerst die Methode der Superklasse auf.
Weiterhin zeigt uns das @Override an, dass wir eine Methode der Superklasse überschrieben haben (und der Compiler meckert uns an wenn, wir sie falsch geschrieben haben -> gängige Fehlerquelle vermieden).

Generell also: 
'''Wenn wir eine Klasse verwenden wollen, legen wir ein Feld mit dem Typ der Klasse an und verwenden das Feld.'''

'''Wenn wir eine bestehende Klasse um neue Funktionalität erweitern wollen, dann erben wir von der Klasse.'''

composition over inheritance

--[[Benutzer:Firephoenix|Firephoenix]] 19:18, 28. Aug 2013 (CET)

[[Kategorie:Java]]

Warum man nicht von JFrame/JDialog erben sollte

2013-08-28T17:16:48Z

Headnut: Die Seite wurde neu angelegt: „== Warum man nicht von JFrame/JDialog erben sollte == Dieser Beitrag wurde von '''Firephoenix''' erstellt Es ist doch verwunderlich wie oft man so etwas hier s…“

== Warum man nicht von JFrame/JDialog erben sollte ==

Dieser Beitrag wurde von '''Firephoenix''' erstellt

Es ist doch verwunderlich wie oft man so etwas hier sieht:

<code=java>public class Gui extends JFrame{

public Gui(){
super("Toller titel");
setDefaultCloseOperation(EXIT_ON_CLOSE);
getContentPane().add(new JButton("sinnloser button"));
pack();
setVisible(true);
}
}</code=java>

Sieht irgendwie bekannt aus, oder?
Und: Normalerweise würgt man die VM auch nicht mit <code=java>System.exit(0);</code=java> respektive <code=java>frame.setDefaultCloseOperation(EXIT_ON_CLOSE);</code=java> ab, sondern ruft <code=java>dispose()</code=java> auf.

Tatsächlich ist der Code genauso furchtbar wie das hier:

<code=java>public class Buchregal extends ArrayList<String>{

public Buchregal(){
add("Spiele programmieren mit Java");
add("Spring im Einsatz");
add("Handbuch der Java Programmierung");
}
}</code=java>

Und mal ehrlich, wer würde auf die Idee kommen, so etwas anzustellen?

Da schreibt man ein Buchregal, das 3 Buchtitel enthält, doch lieber so oder?
(zugegeben es ist kein schönes Buchregal das nur die Titel kennt)

<code=java>public class Buchregal{

private ArrayList<String> buchtitel;

public Buchregal(){
buchtitel = new ArrayList<String>();
buchtitel.add("Spiele programmieren mit Java");
buchtitel.add("Spring im Einsatz");
buchtitel.add("Handbuch der Java Programmierung");
}
}</code=java>

Und genau so kann man auch mit der GUI-Klasse verfahren:

<code=java>public class Gui{

private JFrame frame;

public Gui(){
frame = new JFrame("Toller titel");
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.getContentPane().add(new JButton("sinnloser button"));
frame.pack();
frame.setVisible(true);
}
}</code=java>

Nur was hat man jetzt eigentlich gemacht?

In den ersten 2 Beispielen haben wir Vererbung benutzt, um eine Klasse zu verwenden.
Das Stichwort hier ist "verwenden" und nicht "erweitern"!
Wir haben lediglich bestehende Funktionen der Klasse JFrame verwendet, aber keine neue Funktionalität hinzugefügt.
Solange wir das nicht machen, besteht kein Grund von einer Klasse zu erben!

'''Verwenden != Erweitern'''

{{Zitat
| Autor = L-ectron-X
| Text = Wenn wir von einer Klasse erben, sprechen wir auch davon, sie zu spezialisieren.
Genauso, wie der Vater persönliche Eigenschaften an den Sohn vererbt, bekommt in der OOP eine erbende Klasse die Eigenschaften (Methoden und öffentliche Instanzvariablen) der Basisklasse (auch Superklasse) eingepflanzt. Die erbende Klasse muss aber für eine sinnvolle Anwendung der Vererbung weitere Eigenschaften erhalten, und/oder bestehende Eigenschaften spezialisieren.
Genauso wie der Sohn vom Vater die Fähigkeit erbte, besonders schnell die 60m zu laufen, kann der Sohn nun aber auch noch die 100m besonders schnell laufen. Eine Fähigkeit, zu der der Vater nicht im Stande ist.
}}

Wie es im Englischen schön heißt: composition over inheritance.

Wir benutzen daher möglichst Felder anstatt Vererbung.

Felder können jederzeit ausgetauscht werden, unser Bücherregal könnte zur Programmlaufzeit die ArrayList durch eine LinkedList ersetzen, (oder wenn der typ des Feldes nur Collection <String> wäre), sogar auf ein HashSet umsteigen.
Benutzen wir dagegen Vererbung sind wir für alle Ewigkeit an die ArrayList gebunden und können zur Laufzeit nicht mehr davon weg.
Außerdem wird die Vererbung Teil der API unserer Software, ein anderer Programmierer wird unsere Komponente z.B. auch wie eine ArrayList verwenden, auch hier haben wir keine Möglichkeit etwas zu Ändern ohne anderen Code zu gefährden.
Halten wir dagegen solche Implementierungsdetails in privaten Feldern versteckt können wir zu jeder Zeit daran herumspielen, ohne das jemand etwas davon mitbekommen wird.

Ein Fall wo es tatsächlich Sinn macht von einer Grafikkomponente zu erben wäre dieser hier:

<code=java>public class PaintingPanel extends JPanel{

@Override
public void paintComponent(Graphics g){
super.paintComponent(g);
g.drawLine(3, 3, 6, 6);
}

} </code=java>

Hier haben wir das JPanel tatsächlich erweitert, nämlich um eine hässliche kleine Linie die darauf gezeichnet wird

Zu bemerken ist hier das @Override und der super-Aufruf.
Es ist kein guter Stil, Methoden komplett zu überschreiben (z.B. würde das hier zu Zeichenfehlern im eigentlichen Panel führen), daher rufen wir zuerst die Methode der Superklasse auf.
Weiterhin zeigt uns das @Override an, dass wir eine Methode der Superklasse überschrieben haben (und der Compiler meckert uns an wenn, wir sie falsch geschrieben haben -> gängige Fehlerquelle vermieden).

Generell also: 
'''Wenn wir eine Klasse verwenden wollen, legen wir ein Feld mit dem Typ der Klasse an und verwenden das Feld.'''

'''Wenn wir eine bestehende Klasse um neue Funktionalität erweitern wollen, dann erben wir von der Klasse.'''

composition over inheritance

Benutzer:Headnut

2013-08-28T17:16:14Z

Headnut: Die Seite wurde geleert.

Benutzer:Headnut

2013-08-28T17:11:57Z

Headnut:

== Warum man nicht von JFrame/JDialog erben sollte ==

Dieser Beitrag wurde von '''Firephoenix''' erstellt

Es ist doch verwunderlich wie oft man so etwas hier sieht:

<code=java>public class Gui extends JFrame{

public Gui(){
super("Toller titel");
setDefaultCloseOperation(EXIT_ON_CLOSE);
getContentPane().add(new JButton("sinnloser button"));
pack();
setVisible(true);
}
}</code=java>

Sieht irgendwie bekannt aus, oder?
Und: Normalerweise würgt man die VM auch nicht mit <code=java>System.exit(0);</code=java> respektive <code=java>frame.setDefaultCloseOperation(EXIT_ON_CLOSE);</code=java> ab, sondern ruft <code=java>dispose()</code=java> auf.

Tatsächlich ist der Code genauso furchtbar wie das hier:

<code=java>public class Buchregal extends ArrayList<String>{

public Buchregal(){
add("Spiele programmieren mit Java");
add("Spring im Einsatz");
add("Handbuch der Java Programmierung");
}
}</code=java>

Und mal ehrlich, wer würde auf die Idee kommen, so etwas anzustellen?

Da schreibt man ein Buchregal, das 3 Buchtitel enthält, doch lieber so oder?
(zugegeben es ist kein schönes Buchregal das nur die Titel kennt)

<code=java>public class Buchregal{

private ArrayList<String> buchtitel;

public Buchregal(){
buchtitel = new ArrayList<String>();
buchtitel.add("Spiele programmieren mit Java");
buchtitel.add("Spring im Einsatz");
buchtitel.add("Handbuch der Java Programmierung");
}
}</code=java>

Und genau so kann man auch mit der GUI-Klasse verfahren:

<code=java>public class Gui{

private JFrame frame;

public Gui(){
frame = new JFrame("Toller titel");
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.getContentPane().add(new JButton("sinnloser button"));
frame.pack();
frame.setVisible(true);
}
}</code=java>

Nur was hat man jetzt eigentlich gemacht?

In den ersten 2 Beispielen haben wir Vererbung benutzt, um eine Klasse zu verwenden.
Das Stichwort hier ist "verwenden" und nicht "erweitern"!
Wir haben lediglich bestehende Funktionen der Klasse JFrame verwendet, aber keine neue Funktionalität hinzugefügt.
Solange wir das nicht machen, besteht kein Grund von einer Klasse zu erben!

'''Verwenden != Erweitern'''

{{Zitat
| Autor = L-ectron-X
| Text = Wenn wir von einer Klasse erben, sprechen wir auch davon, sie zu spezialisieren.
Genauso, wie der Vater persönliche Eigenschaften an den Sohn vererbt, bekommt in der OOP eine erbende Klasse die Eigenschaften (Methoden und öffentliche Instanzvariablen) der Basisklasse (auch Superklasse) eingepflanzt. Die erbende Klasse muss aber für eine sinnvolle Anwendung der Vererbung weitere Eigenschaften erhalten, und/oder bestehende Eigenschaften spezialisieren.
Genauso wie der Sohn vom Vater die Fähigkeit erbte, besonders schnell die 60m zu laufen, kann der Sohn nun aber auch noch die 100m besonders schnell laufen. Eine Fähigkeit, zu der der Vater nicht im Stande ist.
}}

Wie es im Englischen schön heißt: composition over inheritance.

Wir benutzen daher möglichst Felder anstatt Vererbung.

Felder können jederzeit ausgetauscht werden, unser Bücherregal könnte zur Programmlaufzeit die ArrayList durch eine LinkedList ersetzen, (oder wenn der typ des Feldes nur Collection <String> wäre), sogar auf ein HashSet umsteigen.
Benutzen wir dagegen Vererbung sind wir für alle Ewigkeit an die ArrayList gebunden und können zur Laufzeit nicht mehr davon weg.
Außerdem wird die Vererbung Teil der API unserer Software, ein anderer Programmierer wird unsere Komponente z.B. auch wie eine ArrayList verwenden, auch hier haben wir keine Möglichkeit etwas zu Ändern ohne anderen Code zu gefährden.
Halten wir dagegen solche Implementierungsdetails in privaten Feldern versteckt können wir zu jeder Zeit daran herumspielen, ohne das jemand etwas davon mitbekommen wird.

Ein Fall wo es tatsächlich Sinn macht von einer Grafikkomponente zu erben wäre dieser hier:

<code=java>public class PaintingPanel extends JPanel{

@Override
public void paintComponent(Graphics g){
super.paintComponent(g);
g.drawLine(3, 3, 6, 6);
}

} </code=java>

Hier haben wir das JPanel tatsächlich erweitert, nämlich um eine hässliche kleine Linie die darauf gezeichnet wird

Zu bemerken ist hier das @Override und der super-Aufruf.
Es ist kein guter Stil, Methoden komplett zu überschreiben (z.B. würde das hier zu Zeichenfehlern im eigentlichen Panel führen), daher rufen wir zuerst die Methode der Superklasse auf.
Weiterhin zeigt uns das @Override an, dass wir eine Methode der Superklasse überschrieben haben (und der Compiler meckert uns an wenn, wir sie falsch geschrieben haben -> gängige Fehlerquelle vermieden).

Generell also: 
'''Wenn wir eine Klasse verwenden wollen, legen wir ein Feld mit dem Typ der Klasse an und verwenden das Feld.'''

'''Wenn wir eine bestehende Klasse um neue Funktionalität erweitern wollen, dann erben wir von der Klasse.'''

composition over inheritance

Benutzer:Headnut

2013-08-28T17:09:02Z

Headnut: Die Seite wurde neu angelegt: „ == Warum man nicht von JFrame/JDialog erben sollte == Dieser Beitrag wurde von '''Firephoenix''' erstellt Es ist doch verwunderlich wie oft man so etwas hier …“

== Warum man nicht von JFrame/JDialog erben sollte ==

Dieser Beitrag wurde von '''Firephoenix''' erstellt

Es ist doch verwunderlich wie oft man so etwas hier sieht:

<code=java>public class Gui extends JFrame{

public Gui(){
super("Toller titel");
setDefaultCloseOperation(EXIT_ON_CLOSE);
getContentPane().add(new JButton("sinnloser button"));
pack();
setVisible(true);
}
}</code=java>

Sieht irgendwie bekannt aus, oder?
Und: Normalerweise würgt man die VM auch nicht mit <code=java>System.exit(0);</code=java> respektive <code=java>frame.setDefaultCloseOperation(EXIT_ON_CLOSE);</code=java> ab, sondern ruft <code=java>dispose()</code=java> auf.

Tatsächlich ist der Code genauso furchtbar wie das hier:

<code=java>public class Buchregal extends ArrayList<String>{

public Buchregal(){
add("Spiele programmieren mit Java");
add("Spring im Einsatz");
add("Handbuch der Java Programmierung");
}
}</code=java>

Und mal ehrlich, wer würde auf die Idee kommen, so etwas anzustellen?

Da schreibt man ein Buchregal, das 3 Buchtitel enthält, doch lieber so oder?
(zugegeben es ist kein schönes Buchregal das nur die Titel kennt)

<code=java>public class Buchregal{

private ArrayList<String> buchtitel;

public Buchregal(){
buchtitel = new ArrayList<String>();
buchtitel.add("Spiele programmieren mit Java");
buchtitel.add("Spring im Einsatz");
buchtitel.add("Handbuch der Java Programmierung");
}
}</code=java>

Und genau so kann man auch mit der GUI-Klasse verfahren:

<code=java>public class Gui{

private JFrame frame;

public Gui(){
frame = new JFrame("Toller titel");
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.getContentPane().add(new JButton("sinnloser button"));
frame.pack();
frame.setVisible(true);
}
}</code=java>

Nur was hat man jetzt eigentlich gemacht?

In den ersten 2 Beispielen haben wir Vererbung benutzt, um eine Klasse zu verwenden.
Das Stichwort hier ist "verwenden" und nicht "erweitern"!
Wir haben lediglich bestehende Funktionen der Klasse JFrame verwendet, aber keine neue Funktionalität hinzugefügt.
Solange wir das nicht machen, besteht kein Grund von einer Klasse zu erben!

'''Verwenden != Erweitern'''

{{Zitat
| Autor = L-ectron-X
| Text = Wenn wir von einer Klasse erben, sprechen wir auch davon, sie zu spezialisieren.
Genauso, wie der Vater persönliche Eigenschaften an den Sohn vererbt, bekommt in der OOP eine erbende Klasse die Eigenschaften (Methoden und öffentliche Instanzvariablen) der Basisklasse (auch Superklasse) eingepflanzt. Die erbende Klasse muss aber für eine sinnvolle Anwendung der Vererbung weitere Eigenschaften erhalten, und/oder bestehende Eigenschaften spezialisieren.
Genauso wie der Sohn vom Vater die Fähigkeit erbte, besonders schnell die 60m zu laufen, kann der Sohn nun aber auch noch die 100m besonders schnell laufen. Eine Fähigkeit, zu der der Vater nicht im Stande ist.
}}

Wie es im Englischen schön heißt: composition over inheritance.

Wir benutzen daher möglichst Felder anstatt Vererbung.

Felder können jederzeit ausgetauscht werden, unser Bücherregal könnte zur Programmlaufzeit die ArrayList durch eine LinkedList ersetzen, (oder wenn der typ des Feldes nur Collection <String> wäre), sogar auf ein HashSet umsteigen.
Benutzen wir dagegen Vererbung sind wir für alle Ewigkeit an die ArrayList gebunden und können zur Laufzeit nicht mehr davon weg.
Außerdem wird die Vererbung Teil der API unserer Software, ein anderer Programmierer wird unsere Komponente z.B. auch wie eine ArrayList verwenden, auch hier haben wir keine Möglichkeit etwas zu Ändern ohne anderen Code zu gefährden.
Halten wir dagegen solche Implementierungsdetails in privaten Feldern versteckt können wir zu jeder Zeit daran herumspielen, ohne das jemand etwas davon mitbekommen wird.

Ein Fall wo es tatsächlich Sinn macht von einer Grafikkomponente zu erben wäre dieser hier:

<code=java>public class PaintingPanel extends JPanel{

@Override
public void paintComponent(Graphics g){
super.paintComponent(g);
g.drawLine(3, 3, 6, 6);
}

} </code=java>

Hier haben wir das JPanel tatsächlich erweitert, nämlich um eine hässliche kleine Linie die darauf gezeichnet wird

Zu bemerken ist hier das @Override und der super-Aufruf.
Es ist kein guter Stil, Methoden komplett zu überschreiben (z.B. würde das hier zu Zeichenfehlern im eigentlichen Panel führen), daher rufen wir zuerst die Methode der Superklasse auf.
Weiterhin zeigt uns das @Override an, dass wir eine Methode der Superklasse überschrieben haben (und der Compiler meckert uns an wenn, wir sie falsch geschrieben haben -> gängige Fehlerquelle vermieden).

Generell also:
'''Wenn wir eine Klasse verwenden wollen, legen wir ein Feld mit dem Typ der Klasse an und verwenden das Feld.'''

'''Wenn wir eine bestehende Klasse um neue Funktionalität erweitern wollen, dann erben wir von der Klasse.'''

composition over inheritance