-
-
Re: The possible future of sun.misc.UnsafeScritto da: ::1
> https://docs.google.com/document/d/1GDm_cAxYInmoHM...
Come conciliare cio' con la patentabita' delle API ?`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: The possible future of sun.misc.UnsafeScritto da: Giambo
>
> Come conciliare cio' con la patentabita' delle API ?
Quello che un po' mi lascia perplesso è come progetti chiave dell'ecosistema java dipendano da una API non documentata e non supportata in alcun modo: hibernate, spring, hadoop, gwt, scala, netty per citarne alcuni non funzionerebbero su java 9 se venisse eliminata.Young professional woman and busy mom.-
Re: The possible future of sun.misc.UnsafeScritto daavvelentaniCubicolarioil 2015-07-11 18:15:13.0 alle 2015-07-11 18:15:13.0Trollate totali: 18184Scritto da: ::1
> Scritto da: Giambo
> >
> > Come conciliare cio' con la patentabita' delle API ?
>
> Quello che un po' mi lascia perplesso è come progetti chiave dell'ecosistema java dipendano da una API non documentata e non supportata in alcun modo: hibernate, spring, hadoop, gwt, scala, netty per citarne alcuni non funzionerebbero su java 9 se venisse eliminata.
perche' ti lascia perplesso? diversi di quei progetti sono performance critical.I think happiness is love
- Vladimir Putin-
Re: The possible future of sun.misc.UnsafeScritto da: avvelentani
>
> perche' ti lascia perplesso? diversi di quei progetti sono performance critical.
Mi lascia perplesso che quei progetti utilizzino in modo così libertino una api non documentata.
Significa che per passare a java 9 si dovrà giocoforza aggiornare quelle librerie, e questo su alcuni progetti, soprattutto molto vecchi, vuol dire riscrivere un sacco di roba.
Ad esempio da me si usa molto spring 2.5, passare al 3.x è uno step che già di suo ha un peso, passare al 4.x ancora di più: se ipotizziamo che esca una fix per spring per togliere la dipendenza e questa va solo sulle ultime versioni allora è un problema.Young professional woman and busy mom.-
Re: The possible future of sun.misc.UnsafeScritto daavvelentaniCubicolarioil 2015-07-11 20:08:18.0 alle 2015-07-11 20:08:18.0Trollate totali: 18184Scritto da: ::1
> Scritto da: avvelentani
> >
> > perche' ti lascia perplesso? diversi di quei progetti sono performance critical.
>
> Mi lascia perplesso che quei progetti utilizzino in modo così libertino una api non documentata.
> Significa che per passare a java 9 si dovrà giocoforza aggiornare quelle librerie, e questo su alcuni progetti, soprattutto molto vecchi, vuol dire riscrivere un sacco di roba.
E` una libreria` che e` li` da decenni e offre funzioni non disponibili altrimenti, non c'e` nulla di strano. Mi sorprende di piu` che java si stia prendendo tutte queste liberta` con la backwards compatibility, come con String.substring.
> Ad esempio da me si usa molto spring 2.5, passare al 3.x è uno step che già di suo ha un peso, passare al 4.x ancora di più: se ipotizziamo che esca una fix per spring per togliere la dipendenza e questa va solo sulle ultime versioni allora è un problema.
Spring e` strano che usi Unsafe, e` un framework inutile quindi non e` possibile che abbia particolari necessita` di performance.I think happiness is love
- Vladimir Putin-
Re: The possible future of sun.misc.UnsafeScritto da: avvelentani
> java si stia prendendo tutte queste liberta` con la backwards compatibility, come con String.substring.
AFAIK in Java7 e' cambiata l'implementazione, non la funzionalita'
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: The possible future of sun.misc.UnsafeScritto daavvelentaniCubicolarioil 2015-07-11 21:37:16.0 alle 2015-07-11 21:37:16.0Trollate totali: 18184Scritto da: Giambo
> Scritto da: avvelentani
>
> > java si stia prendendo tutte queste liberta` con la backwards compatibility, come con String.substring.
>
> AFAIK in Java7 e' cambiata l'implementazione, non la funzionalita'
l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.I think happiness is love
- Vladimir Putin-
Re: The possible future of sun.misc.UnsafeScritto da: avvelentani
> > > java si stia prendendo tutte queste liberta` con la backwards compatibility, come con String.substring.
> >
> > AFAIK in Java7 e' cambiata l'implementazione, non la funzionalita'
>
> l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
Oh beh, finche' non cambia il comportamento, scheissegal
**Modificato dall'autore il 11.07.2015 22:58**`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-11 23:05:51.0 alle 2015-07-11 23:05:51.0Scritto da: Giambo
> Scritto da: avvelentani
>
> > > > java si stia prendendo tutte queste liberta` con la backwards compatibility, come con String.substring.
> > >
> > > AFAIK in Java7 e' cambiata l'implementazione, non la funzionalita'
> >
> > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
>
> Oh beh, finche' non cambia il comportamento, scheiss egal
Bé, insomma... non è sempre così.
Metti che sto facendo una funzione per la verifica di una password in una cassaforte.
Tutte le password sono da 8 caratteri ma so che la funzione che sto usando per confrontare le due password usa un tempo costante per la verifica a prescindere da quale posizione abbia il carattere "diverso". Ora invece me l'ottimizzano così che il confronto termini più velocemente se la password inserita è errata (ovvero si ferma appena trova un carattere discordante).
Mentre prima la mia funzione occupava sempre lo stesso tempo a verificare quegli 8 caratteri, ora la mia funzione termina prima in base a dove si trova il carattere sbagliato nella stringa.
A questo punto con un "power line analysis attack" (ovvero vedo quanto consuma il microprocessore e per quanto tempo) posso facilmente scoprire quella password con (relativamente) pochi tentativi.
È un caso un po' borderline ma come vedi anche una modifica apparentemente così semplice (un'ottimizzazione in questo caso) può rompere qualcosa che prima funzionava con conseguenze anche gravi dal punto di vista del prodotto.-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-12 05:07:28.0 alle 2015-07-12 05:07:28.0chiaro e preoccupante, soprattutto che chi sviluppa queste librerie non faccia di quesrti ragionamenti tuttosommato abbastanza semplici
-
-
Re: The possible future of sun.misc.UnsafeScritto daavvelentaniCubicolarioil 2015-07-12 07:16:57.0 alle 2015-07-12 07:16:57.0Trollate totali: 18184Scritto da: Giambo
> Scritto da: avvelentani
>
> > > > java si stia prendendo tutte queste liberta` con la backwards compatibility, come con String.substring.
> > >
> > > AFAIK in Java7 e' cambiata l'implementazione, non la funzionalita'
> >
> > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
>
> Oh beh, finche' non cambia il comportamento, scheissegal
>
> **Modificato dall'autore il 11.07.2015 22:58**
se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio, non e` difficile che una cosa che terminava nel giro di secondi passi a metterci ore. E l'hanno fatto in una minor release se non ricordo male.I think happiness is love
- Vladimir Putin-
Re: The possible future of sun.misc.UnsafeScritto da: avvelentani
> > > > > java si stia prendendo tutte queste liberta` con la backwards compatibility, come con String.substring.
> > > >
> > > > AFAIK in Java7 e' cambiata l'implementazione, non la funzionalita'
> > >
> > > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
> >
> > Oh beh, finche' non cambia il comportamento, scheissegal
> >
> > **Modificato dall'autore il 11.07.2015 22:58**
>
> se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
Sia come spazio che come tempo ?
Interessante, hai un belink da gettare nella mischia ?`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: The possible future of sun.misc.UnsafeScritto daavvelentaniCubicolarioil 2015-07-12 11:57:05.0 alle 2015-07-12 11:57:05.0Trollate totali: 18184Scritto da: Giambo
> Scritto da: avvelentani
>
> > > >
> > > > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
> > >
> > > Oh beh, finche' non cambia il comportamento, scheissegal
> > >
> > > **Modificato dall'autore il 11.07.2015 22:58**
> >
> > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
>
> Sia come spazio che come tempo ?
> Interessante, hai un belink da gettare nella mischia ?
non ho voglia di cercarlo ma mi pare abbastanza ovvio.I think happiness is love
- Vladimir Putin-
Re: The possible future of sun.misc.UnsafeScritto da: avvelentani
> Scritto da: Giambo
> > Scritto da: avvelentani
> >
> > > > >
> > > > > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
> > > >
> > > > Oh beh, finche' non cambia il comportamento, scheissegal
> > > >
> > > > **Modificato dall'autore il 11.07.2015 22:58**
> > >
> > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> >
> > Sia come spazio che come tempo ?
> > Interessante, hai un belink da gettare nella mischia ?
>
> non ho voglia di cercarlo ma mi pare abbastanza ovvio.
Come sei brontolo stamattina.
Una java.lang.String si compone di tre campi: int offset, int count, char[] value.
Nella vecchia versione di substring veniva ritornata una nuova String contenente lo stesso value, e valori diversi di offset e count; la nuova versione crea una copia di value con esattamente i char necessari.
La differenza è che una volta che la stringa originale cade fuori dal contesto di esecuzione può venire garbage collected anche l'intero value, mentre prima rimaneva sempre vivo.
Questo ha cambiato il comportamento in termini di performances soprattutto per i parser, ma non nel modo terribile che indica sarrusofono perché per molti la differenza è stata poca invece, salvo alcuni edge case.Young professional woman and busy mom.-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-12 12:18:01.0 alle 2015-07-12 12:18:01.0Scritto da: ::1
> Scritto da: avvelentani
> > Scritto da: Giambo
> > > Scritto da: avvelentani
> > >
> > > > > >
> > > > > > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
> > > > >
> > > > > Oh beh, finche' non cambia il comportamento, scheissegal
> > > > >
> > > > > **Modificato dall'autore il 11.07.2015 22:58**
> > > >
> > > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> > >
> > > Sia come spazio che come tempo ?
> > > Interessante, hai un belink da gettare nella mischia ?
> >
> > non ho voglia di cercarlo ma mi pare abbastanza ovvio.
>
> Come sei brontolo stamattina.
> Una java.lang.String si compone di tre campi: int offset, int count, char[] value.
> Nella vecchia versione di substring veniva ritornata una nuova String contenente lo stesso value, e valori diversi di offset e count; la nuova versione crea una copia di value con esattamente i char necessari.
> La differenza è che una volta che la stringa originale cade fuori dal contesto di esecuzione può venire garbage collected anche l'intero value, mentre prima rimaneva sempre vivo.
> Questo ha cambiato il comportamento in termini di performances soprattutto per i parser, ma non nel modo terribile che indica sarrusofono perché per molti la differenza è stata poca invece, salvo alcuni edge case.
Mi sembra di sentire Yoda quando parla dell'ISIS. "Fa parte della loro cultura distruggere la cultura degli altri e salvo alcuni edge case la differenza per molti è stata poca".
-
Re: The possible future of sun.misc.UnsafeScritto da:
> Scritto da: ::1
> > Scritto da: avvelentani
> > > Scritto da: Giambo
> > > > Scritto da: avvelentani
> > > >
> > > > > > >
> > > > > > > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
> > > > > >
> > > > > > Oh beh, finche' non cambia il comportamento, scheissegal
> > > > > >
> > > > > > **Modificato dall'autore il 11.07.2015 22:58**
> > > > >
> > > > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> > > >
> > > > Sia come spazio che come tempo ?
> > > > Interessante, hai un belink da gettare nella mischia ?
> > >
> > > non ho voglia di cercarlo ma mi pare abbastanza ovvio.
> >
> > Come sei brontolo stamattina.
> > Una java.lang.String si compone di tre campi: int offset, int count, char[] value.
> > Nella vecchia versione di substring veniva ritornata una nuova String contenente lo stesso value, e valori diversi di offset e count; la nuova versione crea una copia di value con esattamente i char necessari.
> > La differenza è che una volta che la stringa originale cade fuori dal contesto di esecuzione può venire garbage collected anche l'intero value, mentre prima rimaneva sempre vivo.
> > Questo ha cambiato il comportamento in termini di performances soprattutto per i parser, ma non nel modo terribile che indica sarrusofono perché per molti la differenza è stata poca invece, salvo alcuni edge case.
>
> Mi sembra di sentire Yoda quando parla dell'ISIS. "Fa parte della loro cultura distruggere la cultura degli altri e salvo alcuni edge case la differenza per molti è stata poca".
Dal punto di vista del contratto non è cambiato niente, affidarsi a qualcosa di implicito e non documentato secondo me è sbagliato, avrebbero dovuto invece muoversi per fare entrare nello standard una alternativa valida tramite jsr come si è fatto per altre cose (vedi jsr173 per gli xml, etc etc).Young professional woman and busy mom.-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-12 12:34:31.0 alle 2015-07-12 12:34:31.0Scritto da: ::1
> Scritto da:
> > Scritto da: ::1
> > > Scritto da: avvelentani
> > > > Scritto da: Giambo
> > > > > Scritto da: avvelentani
> > > > >
> > > > > > > >
> > > > > > > > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
> > > > > > >
> > > > > > > Oh beh, finche' non cambia il comportamento, scheissegal
> > > > > > >
> > > > > > > **Modificato dall'autore il 11.07.2015 22:58**
> > > > > >
> > > > > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> > > > >
> > > > > Sia come spazio che come tempo ?
> > > > > Interessante, hai un belink da gettare nella mischia ?
> > > >
> > > > non ho voglia di cercarlo ma mi pare abbastanza ovvio.
> > >
> > > Come sei brontolo stamattina.
> > > Una java.lang.String si compone di tre campi: int offset, int count, char[] value.
> > > Nella vecchia versione di substring veniva ritornata una nuova String contenente lo stesso value, e valori diversi di offset e count; la nuova versione crea una copia di value con esattamente i char necessari.
> > > La differenza è che una volta che la stringa originale cade fuori dal contesto di esecuzione può venire garbage collected anche l'intero value, mentre prima rimaneva sempre vivo.
> > > Questo ha cambiato il comportamento in termini di performances soprattutto per i parser, ma non nel modo terribile che indica sarrusofono perché per molti la differenza è stata poca invece, salvo alcuni edge case.
> >
> > Mi sembra di sentire Yoda quando parla dell'ISIS. "Fa parte della loro cultura distruggere la cultura degli altri e salvo alcuni edge case la differenza per molti è stata poca".
>
> Dal punto di vista del contratto non è cambiato niente, affidarsi a qualcosa di implicito e non documentato secondo me è sbagliato, avrebbero dovuto invece muoversi per fare entrare nello standard una alternativa valida tramite jsr come si è fatto per altre cose (vedi jsr173 per gli xml, etc etc).
Fra poco ci chiederai di postare i link in cui si fa apologia a Java?
-
-
-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-12 13:01:34.0 alle 2015-07-12 13:01:34.0Scritto da: ::1
> Scritto da: avvelentani
> > Scritto da: Giambo
> > > Scritto da: avvelentani
> > >
> > > > > >
> > > > > > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
> > > > >
> > > > > Oh beh, finche' non cambia il comportamento, scheissegal
> > > > >
> > > > > **Modificato dall'autore il 11.07.2015 22:58**
> > > >
> > > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> > >
> > > Sia come spazio che come tempo ?
> > > Interessante, hai un belink da gettare nella mischia ?
> >
> > non ho voglia di cercarlo ma mi pare abbastanza ovvio.
>
> Come sei brontolo stamattina.
Volevo sto completino ma hanno finito la mia misura.
http://www.selfservicesex.it/imageview.php?id=677
> Una java.lang.String si compone di tre campi: int offset, int count, char[] value.
> Nella vecchia versione di substring veniva ritornata una nuova String contenente lo stesso value, e valori diversi di offset e count; la nuova versione crea una copia di value con esattamente i char necessari.
> La differenza è che una volta che la stringa originale cade fuori dal contesto di esecuzione può venire garbage collected anche l'intero value, mentre prima rimaneva sempre vivo.
> Questo ha cambiato il comportamento in termini di performances soprattutto per i parser, ma non nel modo terribile che indica sarrusofono perché per molti la differenza è stata poca invece, salvo alcuni edge case.
-
-
Re: The possible future of sun.misc.UnsafeScritto da: avvelentani
> Scritto da: Giambo
> > Scritto da: avvelentani
> >
> > > > >
> > > > > l'impatto sulla complessita` algoritmica del cambio di implementazione e` stato notevole.
> > > >
> > > > Oh beh, finche' non cambia il comportamento, scheissegal
> > > >
> > > > **Modificato dall'autore il 11.07.2015 22:58**
> > >
> > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> >
> > Sia come spazio che come tempo ?
> > Interessante, hai un belink da gettare nella mischia ?
>
> non ho voglia di cercarlo ma mi pare abbastanza ovvio.
Non e' ovvio per uno che millanta un Master presso l'ETHZ, dimostragli che quel pezzo di carta non vale nulla
!
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: The possible future of sun.misc.UnsafeScritto daavvelentaniCubicolarioil 2015-07-12 13:14:55.0 alle 2015-07-12 13:14:55.0Trollate totali: 18184Scritto da: Giambo
> Scritto da: avvelentani
> > Scritto da: Giambo
> > > Scritto da: avvelentani
> > >
> > > >
> > > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> > >
> > > Sia come spazio che come tempo ?
> > > Interessante, hai un belink da gettare nella mischia ?
> >
> > non ho voglia di cercarlo ma mi pare abbastanza ovvio.
>
> Non e' ovvio per uno che millanta un Master presso l'ETHZ, dimostragli che quel pezzo di carta non vale nulla
!
no, non mi interessa.I think happiness is love
- Vladimir Putin-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-12 13:18:53.0 alle 2015-07-12 13:18:53.0Scritto da: avvelentani
> Scritto da: Giambo
> > Scritto da: avvelentani
> > > Scritto da: Giambo
> > > > Scritto da: avvelentani
> > > >
> > > > >
> > > > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> > > >
> > > > Sia come spazio che come tempo ?
> > > > Interessante, hai un belink da gettare nella mischia ?
> > >
> > > non ho voglia di cercarlo ma mi pare abbastanza ovvio.
> >
> > Non e' ovvio per uno che millanta un Master presso l'ETHZ, dimostragli che quel pezzo di carta non vale nulla
!
>
> no, non mi interessa.
Bravo, però balla con i Bee Gees.
-
Re: The possible future of sun.misc.UnsafeScritto da: avvelentani
> Scritto da: Giambo
> > Scritto da: avvelentani
> > > Scritto da: Giambo
> > > > Scritto da: avvelentani
> > > >
> > > > >
> > > > > se avevi un algoritmo che usava String.substring ed era O(n) nel giro di una release e` diventato O(n²) sia come tempo che come spazio
> > > >
> > > > Sia come spazio che come tempo ?
> > > > Interessante, hai un belink da gettare nella mischia ?
> > >
> > > non ho voglia di cercarlo ma mi pare abbastanza ovvio.
> >
> > Non e' ovvio per uno che millanta un Master presso l'ETHZ, dimostragli che quel pezzo di carta non vale nulla
!
>
> no, non mi interessa.
OK, salvato il messaggio nella cartella "Cazzate di Sarru"
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-11 19:34:49.0 alle 2015-07-11 19:34:49.0Scritto da: ::1
> https://docs.google.com/document/d/1GDm_cAxYInmoHM...
Riassuntino veloce veloce?-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-11 22:32:24.0 alle 2015-07-11 22:32:24.0Scritto da:
> Scritto da: ::1
> > https://docs.google.com/document/d/1GDm_cAxYInmoHM...
>
> Riassuntino veloce veloce?
sun.misc.Unsafe is an unsupported API which has popular usage in the industry but it is not an official standard for Java SE. There are plans for its removal under the modularisation efforts for Java SE 9. This is deemed to be a good thing in general.
Many organisations/framework/library/product owners have stated they will be unable to move to Java SE 9 without some sort of replacement for some of the 'safe' sun.misc.Unsafe features.
The community at large should work on and propose JEPs through OpenJDK to provide the same functionality as the 'safe' parts of of sun.misc.Unsafe. It is generally acknowledged that there will not be enough time for this before Java SE 9 is feature complete (~Nov 2015).
As the JEPs and other pieces of work that make up Java SE 9 will be feature complete in ~Nov 2015, we would like to propose to allow sun.misc.Unsafe to be deprecated and/or be enabled by a -XX flag in order to allow new alternatives for the 'safe' parts of sun.misc.Unsafe to be proposed through the JEP process.
-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-11 22:56:33.0 alle 2015-07-11 22:56:33.0Scritto da:
> Scritto da:
> > Scritto da: ::1
> > > https://docs.google.com/document/d/1GDm_cAxYInmoHM...
> >
> > Riassuntino veloce veloce?
>
> sun.misc.Unsafe is an unsupported API which has popular usage in the industry but it is not an official standard for Java SE. There are plans for its removal under the modularisation efforts for Java SE 9. This is deemed to be a good thing in general.
> Many organisations/framework/library/product owners have stated they will be unable to move to Java SE 9 without some sort of replacement for some of the 'safe' sun.misc.Unsafe features.
> The community at large should work on and propose JEPs through OpenJDK to provide the same functionality as the 'safe' parts of of sun.misc.Unsafe. It is generally acknowledged that there will not be enough time for this before Java SE 9 is feature complete (~Nov 2015).
> As the JEPs and other pieces of work that make up Java SE 9 will be feature complete in ~Nov 2015, we would like to propose to allow sun.misc.Unsafe to be deprecated and/or be enabled by a -XX flag in order to allow new alternatives for the 'safe' parts of sun.misc.Unsafe to be proposed through the JEP process.
>
Cioè prima hanno messo funzioni nella loro libreria che per qualche misteriosa ragione potevano usare solo loro, ora che anche i cani le usano vogliono rimuoverle senza fornire alternative valide a quelle funzione?
Java...
-
Re: The possible future of sun.misc.UnsafeScritto da:
> Scritto da:
> > Scritto da:
> > > Scritto da: ::1
> > > > https://docs.google.com/document/d/1GDm_cAxYInmoHM...
> > >
> > > Riassuntino veloce veloce?
> >
> > sun.misc.Unsafe is an unsupported API which has popular usage in the industry but it is not an official standard for Java SE. There are plans for its removal under the modularisation efforts for Java SE 9. This is deemed to be a good thing in general.
> > Many organisations/framework/library/product owners have stated they will be unable to move to Java SE 9 without some sort of replacement for some of the 'safe' sun.misc.Unsafe features.
> > The community at large should work on and propose JEPs through OpenJDK to provide the same functionality as the 'safe' parts of of sun.misc.Unsafe. It is generally acknowledged that there will not be enough time for this before Java SE 9 is feature complete (~Nov 2015).
> > As the JEPs and other pieces of work that make up Java SE 9 will be feature complete in ~Nov 2015, we would like to propose to allow sun.misc.Unsafe to be deprecated and/or be enabled by a -XX flag in order to allow new alternatives for the 'safe' parts of sun.misc.Unsafe to be proposed through the JEP process.
> >
>
> Cioè prima hanno messo funzioni nella loro libreria che per qualche misteriosa ragione potevano usare solo loro, ora che anche i cani le usano vogliono rimuoverle senza fornire alternative valide a quelle funzione?
>
> Java...
>
Permette di allocare memoria fuori dal garbage collector.Young professional woman and busy mom.-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-11 23:19:33.0 alle 2015-07-11 23:19:33.0Scritto da: ::1
> Scritto da:
> > Scritto da:
> > > Scritto da:
> > > > Scritto da: ::1
> > > > > https://docs.google.com/document/d/1GDm_cAxYInmoHM...
> > > >
> > > > Riassuntino veloce veloce?
> > >
> > > sun.misc.Unsafe is an unsupported API which has popular usage in the industry but it is not an official standard for Java SE. There are plans for its removal under the modularisation efforts for Java SE 9. This is deemed to be a good thing in general.
> > > Many organisations/framework/library/product owners have stated they will be unable to move to Java SE 9 without some sort of replacement for some of the 'safe' sun.misc.Unsafe features.
> > > The community at large should work on and propose JEPs through OpenJDK to provide the same functionality as the 'safe' parts of of sun.misc.Unsafe. It is generally acknowledged that there will not be enough time for this before Java SE 9 is feature complete (~Nov 2015).
> > > As the JEPs and other pieces of work that make up Java SE 9 will be feature complete in ~Nov 2015, we would like to propose to allow sun.misc.Unsafe to be deprecated and/or be enabled by a -XX flag in order to allow new alternatives for the 'safe' parts of sun.misc.Unsafe to be proposed through the JEP process.
> > >
> >
> > Cioè prima hanno messo funzioni nella loro libreria che per qualche misteriosa ragione potevano usare solo loro, ora che anche i cani le usano vogliono rimuoverle senza fornire alternative valide a quelle funzione?
> >
> > Java...
> >
>
> Permette di allocare memoria fuori dal garbage collector.
cioè avete java e avete bisogno di tornare al c
ma java non era diventato superstamegaiperveloce?
-
Re: The possible future of sun.misc.UnsafeScritto da:
> Scritto da: ::1
> > Scritto da:
> > > Scritto da:
> > > > Scritto da:
> > > > > Scritto da: ::1
> > > > > > https://docs.google.com/document/d/1GDm_cAxYInmoHM...
> > > > >
> > > > > Riassuntino veloce veloce?
> > > >
> > > > sun.misc.Unsafe is an unsupported API which has popular usage in the industry but it is not an official standard for Java SE. There are plans for its removal under the modularisation efforts for Java SE 9. This is deemed to be a good thing in general.
> > > > Many organisations/framework/library/product owners have stated they will be unable to move to Java SE 9 without some sort of replacement for some of the 'safe' sun.misc.Unsafe features.
> > > > The community at large should work on and propose JEPs through OpenJDK to provide the same functionality as the 'safe' parts of of sun.misc.Unsafe. It is generally acknowledged that there will not be enough time for this before Java SE 9 is feature complete (~Nov 2015).
> > > > As the JEPs and other pieces of work that make up Java SE 9 will be feature complete in ~Nov 2015, we would like to propose to allow sun.misc.Unsafe to be deprecated and/or be enabled by a -XX flag in order to allow new alternatives for the 'safe' parts of sun.misc.Unsafe to be proposed through the JEP process.
> > > >
> > >
> > > Cioè prima hanno messo funzioni nella loro libreria che per qualche misteriosa ragione potevano usare solo loro, ora che anche i cani le usano vogliono rimuoverle senza fornire alternative valide a quelle funzione?
> > >
> > > Java...
> > >
> >
> > Permette di allocare memoria fuori dal garbage collector.
>
> cioè avete java e avete bisogno di tornare al c
>
> ma java non era diventato superstamegaiperveloce?

È un api di 15 anni fa (almeno java 1.4), viene usata per allocare buffer più performanti di quelli nella vm perché non hanno alcun check a runtime.Young professional woman and busy mom.-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-12 13:28:06.0 alle 2015-07-12 13:28:06.0Scritto da: ::1
> Scritto da:
> > Scritto da: ::1
> > > Scritto da:
> > > > Scritto da:
> > > > > Scritto da:
> > > > > > Scritto da: ::1
> > > > > > > https://docs.google.com/document/d/1GDm_cAxYInmoHM...
> > > > > >
> > > > > > Riassuntino veloce veloce?
> > > > >
> > > > > sun.misc.Unsafe is an unsupported API which has popular usage in the industry but it is not an official standard for Java SE. There are plans for its removal under the modularisation efforts for Java SE 9. This is deemed to be a good thing in general.
> > > > > Many organisations/framework/library/product owners have stated they will be unable to move to Java SE 9 without some sort of replacement for some of the 'safe' sun.misc.Unsafe features.
> > > > > The community at large should work on and propose JEPs through OpenJDK to provide the same functionality as the 'safe' parts of of sun.misc.Unsafe. It is generally acknowledged that there will not be enough time for this before Java SE 9 is feature complete (~Nov 2015).
> > > > > As the JEPs and other pieces of work that make up Java SE 9 will be feature complete in ~Nov 2015, we would like to propose to allow sun.misc.Unsafe to be deprecated and/or be enabled by a -XX flag in order to allow new alternatives for the 'safe' parts of sun.misc.Unsafe to be proposed through the JEP process.
> > > > >
> > > >
> > > > Cioè prima hanno messo funzioni nella loro libreria che per qualche misteriosa ragione potevano usare solo loro, ora che anche i cani le usano vogliono rimuoverle senza fornire alternative valide a quelle funzione?
> > > >
> > > > Java...
> > > >
> > >
> > > Permette di allocare memoria fuori dal garbage collector.
> >
> > cioè avete java e avete bisogno di tornare al c
> >
> > ma java non era diventato superstamegaiperveloce?

>
> È un api di 15 anni fa (almeno java 1.4), viene usata per allocare buffer più performanti di quelli nella vm perché non hanno alcun check a runtime.
che a quanto dite usano ancora tutti-
Re: The possible future of sun.misc.UnsafeScritto daNon Autenticatoil 2015-07-12 13:50:11.0 alle 2015-07-12 13:50:11.0Scritto da:
> Scritto da: ::1
> > Scritto da:
> > > Scritto da: ::1
> > > > Scritto da:
> > > > > Scritto da:
> > > > > > Scritto da:
> > > > > > > Scritto da: ::1
> > > > > > > > https://docs.google.com/document/d/1GDm_cAxYInmoHM...
> > > > > > >
> > > > > > > Riassuntino veloce veloce?
> > > > > >
> > > > > > sun.misc.Unsafe is an unsupported API which has popular usage in the industry but it is not an official standard for Java SE. There are plans for its removal under the modularisation efforts for Java SE 9. This is deemed to be a good thing in general.
> > > > > > Many organisations/framework/library/product owners have stated they will be unable to move to Java SE 9 without some sort of replacement for some of the 'safe' sun.misc.Unsafe features.
> > > > > > The community at large should work on and propose JEPs through OpenJDK to provide the same functionality as the 'safe' parts of of sun.misc.Unsafe. It is generally acknowledged that there will not be enough time for this before Java SE 9 is feature complete (~Nov 2015).
> > > > > > As the JEPs and other pieces of work that make up Java SE 9 will be feature complete in ~Nov 2015, we would like to propose to allow sun.misc.Unsafe to be deprecated and/or be enabled by a -XX flag in order to allow new alternatives for the 'safe' parts of sun.misc.Unsafe to be proposed through the JEP process.
> > > > > >
> > > > >
> > > > > Cioè prima hanno messo funzioni nella loro libreria che per qualche misteriosa ragione potevano usare solo loro, ora che anche i cani le usano vogliono rimuoverle senza fornire alternative valide a quelle funzione?
> > > > >
> > > > > Java...
> > > > >
> > > >
> > > > Permette di allocare memoria fuori dal garbage collector.
> > >
> > > cioè avete java e avete bisogno di tornare al c
> > >
> > > ma java non era diventato superstamegaiperveloce?

> >
> > È un api di 15 anni fa (almeno java 1.4), viene usata per allocare buffer più performanti di quelli nella vm perché non hanno alcun check a runtime.
>
> che a quanto dite usano ancora tutti
Javari irresponsabili!
-
-
-
-
-
-
-
-