[java] niet echte modal dialog.

[Alarmnummer]

Ik heb een dialog nodig waardoor het niet meer mogelijk is om op de achtergrond nog op knoppen te kunnen drukken. Helaas is een modal dialog voor mij niet geschikt, omdat ik een thread heb draaien op de achtergrond, die zo nu en dan events verstuurd (op de swingthread wel te verstaan) waardoor de gui geupdate wordt. Als ik een modal dialog gebruik, dan wordt de gui dus niet meer geupdate.

[Confusion]

Alleen de draad die setVisible aanroept wordt geblockt volgens http://www.absolutejava.com/swing/. Misschien ff de aanroep in een extra draadje gieten?

[yrew]

Wordt met een modal dialog alleen de gui thread gestopt? Of wordt de volledige thread gestopt en de dialog in een andere thread opgestart?

[Alarmnummer]

De gui thread die wordt niet zozeer gestopt, maar verwerkt geen events meer voor andere schermen.

[mbravenboer]

Tja, je zou zelf de events kunnen verwerken en beslissen welke je wel en niet toelaat. Deze taktiek wordt gebruikt in m'n JInternalFrame met modal mogelijkheid. Je kan zo wel iets werkends krijgen, maar meestal vergeet je toch allerlei dingetjes. Als je de events echter uniek kan aanduiden, is er wel een kans dat je het netjes voor elkaar krijgt.

[Alarmnummer]

Ik had al iets gelezen over een glasplane op te wippen op het te disablen scherm. Die glasplane vangt dan de events af. Ik vind het jammer dat dit de enigste oplossing is die ik eigelijk heb gevonden.

[mbravenboer]

Yepz, die heb ik ook weleens gezien als oplossing voor modal JInternalFrames ja. Volgens mij in een artikel van Sun zelf. Vind het filteren van die events toch fraaier eerlijk gezegd. Kan je nog een mooi ontwerpje van maken .

[Alarmnummer]

mbravenboer schreef op 28 July 2003 @ 10:00:
Yepz, die heb ik ook weleens gezien als oplossing voor modal JInternalFrames ja. Volgens mij in een artikel van Sun zelf. Vind het filteren van die events toch fraaier eerlijk gezegd. Kan je nog een mooi ontwerpje van maken .

pfff.. *heeft nog meeeeeer dan genoeg te doen*

-afronden vragenscherm
-inbouwen van de queries in de inference engine (en ook beetje efficient ipv db leegtrekken)
-preselectie scherm
-feiten scherm (db overzicht.. maar dan voor juristen)

en dan natuurlijk nog oppoetsen van oude code.. Jezus.. wat programmeerde ik 1 a 2 jaar geleden (zo lang is het geleden dat ik daar iets aan heb gedaan) nog irritant zeg. *geeft zichzelf al een klap voor de visie die hij over 1 a 2 jaar over zichzelf op dit tijdstip heeft*

[mbravenboer]

Tssss .... zat net aan een chain of responsibility te denken . Tik maar gewoon een beetje door!

[Alarmnummer]

Waar doel je trouwens op met de laatste regel van je sig? Die nieuwe variant syntax die zo aan verandering onderhevig is?

[mbravenboer]

Ik kon helaas de link naar de bron niet meer toevoegen ivm de toegestane omvang van een sig. Hij komt hier uit: Types and Programming Languages, the Next Generation. De opmerking slaat daar niet direct op Java Generics, maar ik vind hem van toepassing op Java Generics.

Ik heb hem opgenomen en toegewezen aan Java Generics omdat ik denk dat de bezwaren die je regelmatig hoort over de 'complexiteit' van Java Generics niet zozeer tegen het krachtigere type-systeem zijn gericht. In principe geeft alleen het bestaan van de kritiek al aan dat er iets mis is.

Het is helaas niet leuk (ingewikkeld) is om zelf voortdurend te noteren wat het type van alles is. Deze opmerking in de slides geeft dat precies aan. Ik denk dat het hoog tijd wordt om de invoering van leukere type systemen te combineren met het invoeren van type inferentie, wat uiteraard niet het verzwakken van typering betekent. Hierbij hoef je niets te verliezen, behalve de ergernis van het noteren van elk onbenullig type. Het halfslachtige is dat er al wel enkele inferentie in zit bij parameters van geparameterizeerde methoden. Toen ik voorstelde om deze inferentie ook voor constructoren in te voeren begonnen ze te zeuren over de niet-inferentie aard van de taal Java.

Helaas gaat de discussie nu vaak over statische versus dynamische typering. Op zich niet zo gek omdat statisch en dynamisch elkaars tegenovergesteld lijken. Veel van de voordelen van sterke typering vaak toegewezen aan statische typering, waardoor de discussie niet zo opschiet. Ik hoor liever iets over de mogelijkheden om een taal sterk getypeerd te maken. Statische typering interesseert me niet en lijkt me eerder een beperking dan een pluspunt.

[mbravenboer]

Het draait trouwens niet in het bijzonder om de variantie, alhoewel dat de types wel nog wel complexer maakt en dus minder leuk om te noteren. Variantie is trouwens volledig gedropt uit de laatste early access. Ze hebben nog een soort wannabe syntax (het ?), maar dat is niets meer dan suiker voor wat al mogelijk was voor de voorstellen rond variantie.

Heel jammer, want de invoering van variantie was een unieke kans geweest om je te onderscheiden als taal. Parameters zijn nu nog steeds invariant omdat ze gebruikt worden voor zowel argumenten als return typen.

[Alarmnummer]

mbravenboer schreef op 28 July 2003 @ 11:39:
Helaas gaat de discussie nu vaak over statische versus dynamische typering. Op zich niet zo gek omdat statisch en dynamisch elkaars tegenovergesteld lijken. Veel van de voordelen van sterke typering vaak toegewezen aan statische typering, waardoor de discussie niet zo opschiet. Ik hoor liever iets over de mogelijkheden om een taal sterk getypeerd te maken. Statische typering interesseert me niet en lijkt me eerder een beperking dan een pluspunt.

Mijn mening is hierover een beetje verdeeld. Ik vind zo nu en dan het gebrek aan expliciete typeinformatie wel vervelend bij Haskell of Clean bv. Ik schrijf dan toch liever de types erbij, zodat ik kan zien wat ik bedoel. Maar in sommige gevallen is het idd niet nodig (zoals bij methode aanroepen) om die zelf te gaan parametriseren (zou er niet aan moeten denken en ik heb ook meteen een type-inferentie mechanisme geschreven voor mijn typesysteem die verder alleen invariant is op de typeargumenten)

Ik ga trouwens binnnekort eens experimenteren met Jython. Jython heeft ook een dynamisch typesysteem en dat kan idd voor sommige zaken heel geschik zijn. Ik denk alleen dat je voor serieuze toepassingen zo veel mogelijk statisch wilt kunnen controleren. Voor een gui is het een minder groot probleem als het niet helemaal werkt zoals het moet, daarom daar dan ook dynamisch toelaten?

[Alarmnummer]

mbravenboer schreef op 28 juli 2003 @ 11:42:
Variantie is trouwens volledig gedropt uit de laatste early access. Ze hebben nog een soort wannabe syntax (het ?), maar dat is niets meer dan suiker voor wat al mogelijk was voor de voorstellen rond variantie.

*zucht* Dit is nu definitief?

[mbravenboer]

Alarmnummer: Ik vind zo nu en dan het gebrek aan expliciete typeinformatie wel vervelend bij Haskell of Clean bv. Ik schrijf dan toch liever de types erbij, zodat ik kan zien wat ik bedoel.

Type inferentie wil natuurlijk niet zeggen dat je helemaal geen types meer kan aangeven. In Haskell kan je bijvoorbeeld gewoon het type van functies opgeven. Als hetgene wat de type inferentie uitvindt daar niet mee overeenkomt, krijg je een foutmelding.

Ik ga trouwens binnnekort eens experimenteren met Jython.

Python is best leuk. Heb er een tijdje geleden voor het eerst een min of meer serieus programma in geschreven. Alleen maar de tutorial doorkijken is leuk, maar je weet pas echt hoe het voelt als je er ook in programmeert .... Vooral de library is lekker. Erg uitgebreid. Het enige wat ik wel vrij onduidelijk vind is de vele opmerkingen over bijvoorbeeld 'file-like' objecten. Alleen door het bestaan van attributen en methoden implementeer je al een soort interface (duck-typing), maar vaak wordt er slechts een subset van een interface geimplementeerd. Het is slecht gedocumenteerd welke mogelijkheden er precies beschikbaar zijn als dit het geval is.

[mbravenboer]

Alarmnummer: *zucht* Dit is nu definitief?

Ben bang van wel. Er zijn nu dus alleen nog wildcards. Tja, leuk ...

[Alarmnummer]

mbravenboer schreef op 28 July 2003 @ 12:00:
[...]

Type inferentie wil natuurlijk niet zeggen dat je helemaal geen types maar kan aangeven. In Haskell kan je bijvoorbeeld gewoon het type van functies opgeven. Als hetgene wat de type inferentie uitvindt daar niet meer overeen komt, krijg je een foutmelding.

Het gaat mij erom dat je dan ook sourcecode van een ander kan krijgen die impliciet getypeerd is. Dit kan het gebruik van een api een stuk lastiger maken.

Maarja.. zoals voor alle krachtige features geldt, je kan het ook verkeerd gebruiken. Dit kan je niet de feature verwijten.

[Soultaker]

Nu we het toch even over Java 1.5 hebben, wil ik er uit gemakzucht een snel vraagje tussendoor vrotten: is het nu zo dat Java Generics een soort templates worden a la C++ (die bij het compileren worden geïnstantieerd) of worden daadwerkelijk parametriseerbare typen gecompileerd (die pas at runtime worden geïnstantieerd)?

[mbravenboer]

Alarmnummer: Het gaat mij erom dat je dan ook sourcecode van een ander kan krijgen die impliciet getypeerd is. Dit kan het gebruik van een api een stuk lastiger maken.

Ja, das op zich wel een punt. Je kan ecjter wel altijd het type van een functie uitvinden. In Hugs kan je bijvoorbeeld van alle functies het type opvragen, ook als dat niet aangegeven is. Een goed tooltje wat API docs genereert zou dit ook moeten doen en dit type dan opnemen in de docs.

[Alarmnummer]

Soultaker schreef op 28 July 2003 @ 12:06:
Nu we het toch even over Java 1.5 hebben, wil ik er uit gemakzucht een snel vraagje tussendoor vrotten: is het nu zo dat Java Generics een soort templates worden a la C++ (die bij het compileren worden geïnstantieerd) of worden daadwerkelijk parametriseerbare typen gecompileerd (die pas at runtime worden geïnstantieerd)?

Eigelijk geen van beiden Java gebruikt de typeinformatie alleen tijdens het compileren en veder wordt er runtime niets meer mee gedaan. Het wordt wel meegenomen in een attribuut, maar je krijgt geen runtime error als je iets doet dat niet door de type-beugel kan.

[ Voor 4% gewijzigd door Alarmnummer op 28-07-2003 12:10 ]

[mbravenboer]

Soultaker: uit gemakzucht een snel vraagje

Lui kreng!

Is het nu zo dat Java Generics een soort templates worden a la C++

Nee.

worden daadwerkelijk parametriseerbare typen gecompileerd

Java Generics worden gecompileerd met type erasure. Dit is wel een aardige bron:
http://www-106.ibm.com/de...djc03113.html?dwzone=java

Als er commentaar wordt geleverd op de zwakke manier van compileren, is de reactie vaak dat het systeem in de toekomst krachtiger gemaakt kan worden met behoud van de bestaande syntax. Op zich hebben ze daar wel een punt. Er zijn verschillende papers geschreven over andere compilatie modellen en de gevolgen daarvan op de bytecode en de vm. In het artikel hierboven staan wel wat referenties.

[mbravenboer]

Grappig trouwens dat een willekeurig java topic met enige regelmaat uitloopt een generics topic .

Ik zie dat je toch ff moeten zoeken totdat je bij Project NextGen uitkomt. Bij deze dus .

[ Voor 47% gewijzigd door mbravenboer op 28-07-2003 12:17 ]

[Alarmnummer]

Misschien omdat we er nu ook eindelijk over mee kunnen praten

[Soultaker]

mbravenboer schreef op 28 July 2003 @ 12:14:
Ik zie dat je toch ff moeten zoeken totdat je bij Project NextGen uitkomt. Bij deze dus .

Maar als ik het goed begrijp kun je er dan nog steeds alleen maar Object's in stoppen, omdat alle afgeleide typen een algemene implementatie met Object references gebruiken? En dus kun je er nog steeds container met primitive waarden maken? Of mis ik nu iets?

Zelfs als de compiler die conversies uitvoert, is het nog steeds wel ontzettend vervelend (in termen van efficiëntie) om voor elke primitieve waarde een object te instantiëren. Het leuke van C++ is dat het gebruik van een std::vector een acceptabel alternatief is voor een C-style array. In Java wil ik ook graag Container klassen gebruiken in plaats van arrays, maar als er dan nog steeds alleen maar object references in kunnen, wordt hun bruikbaarheid nogal beperkt.

[mbravenboer]

Soultaker: Maar als ik het goed begrijp kun je er dan nog steeds alleen maar Object's in stoppen

Dat begrijp je goed ...

En dus kun je er nog steeds container met primitive waarden maken?

Ik maak uit de context op dat hier een essentieel woordje mist: "geen" .

Zelfs als de compiler die conversies uitvoert, is het nog steeds wel ontzettend vervelend (in termen van efficiëntie) om voor elke primitieve waarde een object te instantiëren.

Yepz. Je hebt eigenlijk een goede compiler nodig die dergelijke optimalisaties kan uitvoeren. De scheiding tussen primitieven en objeten moet opgheven worden. Beide toestaan op allerlei plaatsen is een ad-hoc fix om de scheiding minder zichtbaar te maken.

[Soultaker]

mbravenboer schreef op 28 July 2003 @ 13:53:
Ik maak uit de context op dat hier een essentieel woordje mist: "geen" .

Uhh, idd, ja.

Yepz. Je hebt eigenlijk een goede compiler nodig die dergelijke optimalisaties kan uitvoeren. De scheiding tussen primitieven en objeten moet opgheven worden. Beide toestaan op allerlei plaatsen is een ad-hoc fix om de scheiding minder zichtbaar te maken.

Maar dat kan dus geen JIT-compiler zijn, want de JVM code bevat geen informatie meer over generieke typen en er is alleen (bijvoorbeeld) een Vector gebaseerd op object references. In theorie kun je dan nog wel het een en ander over de mogelijke typen afleiden, maar ik kan me voorstellen dat dat te ingewikkeld wordt om daadwerkelijk te gaan werken.

Dat betekent dat de Java compiler toch weer code voor aparte klassen moet gaan genereren, lijkt me, of er moet een fundamentele wijziging in de bytecode specificatie komen. Op zich zie ik het nadeel van extra code genereren niet in, of het moet de code size zijn. Dit lijkt me vooral van belang voor embedded devices (en eventueel applets ofzo, maar dat is toch al nauwelijks relevant). Op zich zou het ook een optimalisatie kunnen zijn die niet altijd uitgevoerd wordt.

Een groot voordeel van aparte code genereren lijkt me dat je alle runtime casts er ook uit kunt gooien. Ik weet niet in hoeverre een JIT compiler dat soort optimalisaties nu ook al kan uitvoeren; het lijkt me erg lastig om te garanderen dat bepaalde attributen bepaalde typen hebben, tenzij al je methoden final zijn, en je dus alle mogelijke assignments aan attributen kunt checken.

[Alarmnummer]

Soultaker schreef op 28 July 2003 @ 14:21:
Maar dat kan dus geen JIT-compiler zijn, want de JVM code bevat geen informatie meer over generieke typen en er is alleen (bijvoorbeeld) een Vector gebaseerd op object references.

Er wordt nog wel wat geparametriseerde typeinformatie meegenomen in een bepaald attribuut in de bytecode. Dit maakt het mogelijk om met generics en classfiles te werken.

Dat betekent dat de Java compiler toch weer code voor aparte klassen moet gaan genereren, lijkt me, of er moet een fundamentele wijziging in de bytecode specificatie komen.

Java die genereerd eigelijk ook 1 speciale class. Stel dat je de volgende geparametriseerde class hebt:

code:

class List<E>{
   add(E item){...}
}

Als je deze gaat compileren, dan wordt E vervangen door object (omdat object het grootste voorkomen van E is). Als je het volgende zegt:

code:

class PersoonList<E extends Persoon>{
      add(E persoon)
}

Dan vervangt de compiler E door Persoon en dat is dan de uiteindelijke class die je krijgt.

En ander leuk probleem wat je tegenkomt is het volgende:

code:

class Onzin<A,B>{
      add(A a){...}
      add(B b){...}
}

Als de compiler A en B gaat vervangen door object, wat gebeurt er met de signatures van add?

Op zich zie ik het nadeel van extra code genereren niet in, of het moet de code size zijn.

1 nadeel is idd de code explosie. De compiler kan nooit nagaan hoe 'diep'je bv gaat en zal statisch alle geparametriseerde types moeten aanmaken. Een leuk probleem wat hierbij optreed is polymorfe recursie:

code:

void onzin(List<A> l){
      onzin(new List<List<A>>());
}

Als je deze functie gaat aanroepen met List<Int> dan zal de volgende aanroep zijn List<List<Int>> en je kan wel aanvoelen dat dit niet gaat aflopen. Het voordeel aan de aanpak van java is dat dit dus geen problemen gaat opleveren. De aanpak van Gyro is trouwens nog een stuk beter. Hierbij maken ze de types gewoon lazy. Runtime wordt als het nodig nieuwe stukken code aangemaakt en gecompileerd.

[ Voor 4% gewijzigd door Alarmnummer op 29-07-2003 11:46 ]