Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alessio Stalla
    @alessiostalla
    Infatti. Il problema lo hai se, mentre il costruttore è in esecuzione, esponi il this ad altri thread. Ma in x = new X() l'assegnazione avviene dopo che il costruttore ha finito il suo lavoro. Quello che può capitare al massimo è che venga costruita più di una istanza.
    Felice Pagano
    @felicepagano
    sisi, mi sono inventato qualcosa di assurdo. ragionandoci su sarebbe stato un problema fare nello stesso thread.
    var x = new X(); x.getQualcosa():
    Francesco Guardiani
    @slinkydeveloper
    Luca Molteni
    @lucamolteni
    @franz1981 mentre si discuteva sull'usare java.nio.Paths invece che concatenare stringhe ho ottenuto questa come risposta
    PathVsStringBenchmark.testPath avgt 10 0.481 ± 0.025 us/op PathVsStringBenchmark.testString avgt 10 0.004 ± 0.001 us/op
    Antonio Gelameris
    @toniogela_twitter
    Solo due ordini di grandezza
    Andrea Peruffo
    @andreaTP
    @lucamolteni ci sono da poco rimasto male pure io, entrambi Path e File sono incredibilmente piu' lenti che lavorare sulle stringhe
    Antonio Gelameris
    @toniogela_twitter
    senza fare nessun tipo di verifica di esistenza?
    Luca Molteni
    @lucamolteni
    però secondo me va sempre contestualizzato
    quante volte concatenerai path in un loop?
    Andrea Peruffo
    @andreaTP
    tantissime!!!! Conta che lavoriamo sui git-tree ....
    Andrea Peruffo
    @andreaTP
    Un po' di pubblicità senza pudore:
    Luca Molteni
    @lucamolteni
    ho paura di sapere cos'è la 12 factor configuration
    Andrea Peruffo
    @andreaTP
    https://12factor.net/config
    la configurazione va passata con variabili di ambiaente TL;DR;
    Luca Molteni
    @lucamolteni
    grazie @andreaTP :)
    Andrea Peruffo
    @andreaTP
    paroloni XD
    Antonio Gelameris
    @toniogela_twitter
    HOCON è così bello rispetto a Json <3
    Francesco Nigro
    @franz1981
    @lucamolteni non ho il codice del bench!
    sparalo :)
    Luca Molteni
    @lucamolteni
    eh manco io
    :D
    Francesco Nigro
    @franz1981
    @lucamolteni Allora non so se è corretto :D

    @felicepagano

    da quello che ricordo la creazione di un'instanza di un oggetto non è un' operazione atomica

    In realtà lo è (se almeno uno dei campi dell'instanza è final), ma relativamente a successive scritture: cioè se vi sono scritture successive di qualsiasi genere (magari facenti uso di dati dalla istanza appena creata) non possono essere percepite come antecedenti la creazione dell'istanza.
    O meglio ancora:
    x = new X();
    y = x;
    La scrittura y = x non può ricevere alcun valore corrotto di nessuno dei campti di x SE almeno uno di essi è final

    Francesco Nigro
    @franz1981
    Per chi fosse amante di prog concorrente: JCTools/JCTools#245
    Se tutto va bene la migliorerò nelle settimane prossime, ma dovrebbe essere giusta....
    Qualora dovesse essere veloce come sembra dai bench, la versione single consumer (tipica da event loop) dovrebbe finire in Akka o Netty, vedremo...
    Antonio Gelameris
    @toniogela_twitter
    Hello hello
    Nessuno scrive da un sacco oramai :(
    Luca Molteni
    @lucamolteni
    veramente
    siete andati a mangiare le braciole?
    Gian Carlo Pace
    @gicappa
    YES
    una cenetta light
    costine patate e birra
    Luca Molteni
    @lucamolteni
    grandi
    Andrea Peruffo
    @andreaTP
    Buongiorno a tutti amici javisti, ieri ho visto una cosa che mi ha fortemente spaventato e credo di non sapere piu' Java quindi chiedo supporto

    allora ho una classe:

    import io.atlassian.fugue.Either;
    
    public class E1 {
      public Either<Exception, String> example() {
        return Either.right("");
      }
    }

    e la estendo come:

    import io.atlassian.fugue.Either;
    
    public class E2 extends E1 {
    
      @Override
      public Either<String, Exception> example() {
        return Either.left(new Exception());
      }
    }

    notate che in E2 la signature del tipo di ritorno ha i generici invbertiti, e tutto cio' con mia enorme sorpresa compila

    la dipendenza e':

        <dependency>
          <groupId>io.atlassian.fugue</groupId>
          <artifactId>fugue</artifactId>
          <version>4.7.1</version>
        </dependency>

    con interfacce e classi definite da me nonn riesco a riprodurre

    Bradipo Developer
    @BradipoDev_twitter
    Ciao. Dunque, se non ricordo male nell'override dei metodi è consentito cambiare il tipo di ritorno sotto certe condizioni, una delle quali è che il secondo tipo sia una specializzazione del primo. Sinceramente non so come inquadrare un caso del genere :-)
    Francesco Nigro
    @franz1981
    Bè mi fa strano compili ma non così strano se consideriamo che i generics esistono solo a compile time..hai provato ad abilitare i compiler warns?
    Mi aspetterei che perlomeno qualcosa te la dica
    Felice Pagano
    @felicepagano
    io non riesco a compilarlo quel codice
    Francesco Nigro
    @franz1981
    Ci credo..dovrebbe arrabbiarsi (in teoria)
    Però è anche vero che forse può essere forzato
    credo che Either<X,Y> lo risolva come un Either
    raw type
    Andrea Peruffo
    @andreaTP
    Il compilatore e' felice gli IDE no
    e non riesco veramente a capire

    il pom.xml:

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
      <modelVersion>4.0.0</modelVersion>
      <groupId>com.example</groupId>
      <artifactId>example</artifactId>
      <packaging>jar</packaging>
      <version>1.0-SNAPSHOT</version>
      <name>example</name>
      <url>http://maven.apache.org</url>
      <dependencies>
        <dependency>
          <groupId>io.atlassian.fugue</groupId>
          <artifactId>fugue</artifactId>
          <version>4.7.1</version>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>3.8.1</version>
          <scope>test</scope>
        </dependency>
      </dependencies>
    </project>

    e mvn compile

    Felice Pagano
    @felicepagano
    javac MainFUgue.java -cp ~/.m2/repository/io/atlassian/fugue/fugue/4.7.1/fugue-4.7.1.jar
    MainFUgue.java:23: error: example() in E2 cannot override example() in E1
        public Either<String, Exception> example() {
                                         ^
      return type Either<String,Exception> is not compatible with Either<Exception,String>
    MainFUgue.java:22: error: method does not override or implement a method from a supertype
        @Override
        ^
    MainFUgue.java:24: error: incompatible types: inference variable L has incompatible bounds
            return Either.left(new Exception());
                              ^
        equality constraints: String
        lower bounds: Exception
      where L,R are type-variables:
        L extends Object declared in method <L,R>left(L)
        R extends Object declared in method <L,R>left(L)
    3 errors
    Felice Pagano
    @felicepagano
    credo che dipenda dal fatto che maven, configurato in quel modo, imposti il language level alla versione 5 di default
    Felice Pagano
    @felicepagano
    l’unica discriminante che mi viene in mente è quella. poi perchè java 5 te lo faccia fare non saprei :D. a memoria in java 5 i generics non erano obbligatori, magari per questo motivo è più permissivo