Wrapper knihovní třídy

Ta je vyhazována na řádce, kde se pokouším přetypovat VEvent na MyEvent.

mozes sem dat ten riadok? Ptz to sa neda pretypovavat (resp. minimalne nie tym smerom), skus si urobit objekty triedy MyEvent, a ne objekty triedy VEvent.

public static TreeSet<MyEvent> loadEvents(InputStreamReader input) throws IOException, ParserException{
		TreeSet<MyEvent> events = new TreeSet<MyEvent>();
		CalendarBuilder builder = new CalendarBuilder();
		Calendar calendar = builder.build(input);
		ComponentList cl = calendar.getComponents(Component.VEVENT);
		MyEvent event;
		//String summary;
		//Property property;
		for(int i = 0 ; i < cl.size() ; i++){
			event = (MyEvent) cl.get(i);
			//summary = event.getProperty(Property.SUMMARY).getValue();
			//System.out.print(summary);
			//property = event.getProperty(Property.RRULE);
			//if(property != null){

			//}
			//System.out.println(event.toString());
			events.add(event);
		}
		return events;
	}

Výjimka je vyhazována na první řádce v cyklu.
cl.get(i) vrací objekt typu Object

Takze tie VEvent objekty sa vytvoria v tom new CalendarBuilder() a nemozes nijak ovplyvnit aby v tom calendari boli MyEvent a ne VEvent objekty?
Inac to riesit neviem :) (mozno los alebo niekto napise nieco lepsie)

Jo, ty komponenty vytváří už CalendarBuilder sám a neovlivním to.

No ovlivnis to ked zmenis ten CalendarBuilder kdesi v jeho zdrojakoch :) (resp. to si tam potom rovno mozes pridat tu fuknciu do toho VEvent a nerobit vobec MyEvent :)

To už si myslím, že je proti licenci, nebo?

preco? je to opensource ci ne? http://build.mnode.org/projects/ical4j/license.htm l
Ja neviem ja to nepouzivam. Alebo mozes si urobit u seba aj nejaky MyCalendar zdedny z original calendara a prerobit ho apod., moznych rieseni je viac, otazka ze co je najjednoduchsie.

Ale to co pisal nizsie MaSo je asi najjednoduchsie. Ak ti nevadi ze tie data mas na 2 miestach (raz v kanelndari a raz v tom sort zozname)

Nevadí, na přehlednosti si myslím, že to nestrádá.

Jsou to reference, takže v tom bych problém neviděl...

Reference to snad neni, vytvaras si vlastny objekt. Keby to bola reference tak je cela java na hlavu (mozno je, preto ma nezaujima :D). Jak by si potom skopiroval objekt a menil len skopirovany?
P.S. napr.
AUTO Auto1, Auto2;
Auto1.znacka=Skoda;
Auto1.farba=Cervena;
Auto2=Auto1;
Auto2.farba=Modra;
- tvrdis ze v jave sa tym zmenil aj Auto1? (potom povazujem javu za uplne na hlavu :)

Přesně tak, zkopíruješ referenci, ne objekt... barva se změní v obou autech. Mě to přijde docela logické, proč by to mělo být na hlavu?

pretoze si vytvoril 2 objekty. Prvy zapis (AUTO Auto1;) vytvoril pamatove miesto pre data, druhy STEJNY zapis nevytvoril pamatove miesto. Je to nedeterministicke.

Auto auto1, auto2;

V Javě znamená:

Auto auto1 = null;
Auto auto2 = null;

takto (C++ zapis):
Auto *auto1 = null;
Auto *auto2 = null;
Prave tou * poviem ze co presne chcem od toho kramu, preto je C++ deterministicke ;) Ok tak uz viem ze v jave su len smerniky a miesto pre data alokuje nejaky duch nahodne, este par diskusii a budem moct robit aj v jave ;DD

resp. tak jak to popisujete tak mi tam asi chyba riadok Auto1 = new AUTO; ? Potom ok je to deterministicke

Jo, chybí tam volání konstruktoru, to jsem si ani nevšiml...:)

A navyse potom musis riesit taketo hovadiny http://stackoverflow.com/questions/3144673/java-ob ject-copy-best-option. Ano uz som si to nasiel googlom kopiruje to v jave len referenciu mate pravdu :)

Ano. V Javě jsou všechno reference (kromě primitivních typů), když chceš deepcopy, tak si musíš vytvořit nový objekt přes konstruktor a fieldy překopírovat ručně...

iCal4j neznám, ale chápu-li správně o co se tady snažíš, tak bych to udělal následovně:

public class MyEvent implements Comparable<MyEvent> {

    private VEvent event;

    public MyEvent (VEvent event) {
         this.event = event;
    }
   
    // muzes si i v pripade nutnost "zviditelnit" i ostani metody VEventu v MyEventu prostym delegovanim volani
 
    public VEvent getVEvent() { return this.event; }

    public int compareTo( MyEvent myEvent ) {
        // implementace porovnavaci metody 
        // k 1. VEeventu se dostanes pres field event k 2. pres myEvent.getVEvent()
    }
}

v tom cyklu pak bude:

public static TreeSet<MyEvent> loadEvents(InputStreamReader input) throws IOException, ParserException{
		TreeSet<MyEvent> events = new TreeSet<MyEvent>();
		CalendarBuilder builder = new CalendarBuilder();
		Calendar calendar = builder.build(input);
		ComponentList cl = calendar.getComponents(Component.VEVENT);
	        VEvent event;
		//String summary;
		//Property property;
		for(int i = 0 ; i < cl.size() ; i++){
			event = (VEvent) cl.get(i);
			//summary = event.getProperty(Property.SUMMARY).getValue();
			//System.out.print(summary);
			//property = event.getProperty(Property.RRULE);
			//if(property != null){

			//}
			//System.out.println(event.toString());
			events.add(new MyEvent(event));
		}
	

Vidíš, atribut není špatný nápad.
Díky.

No to jistě není. V OOP vždy upřednostňuj skládání před dědičností.