Link alla notizia: http://www.hwupgrade.it/news/telefonia/android-dice-addio-alle-api-java-di-oracle-spazio-a-openjdk_60089.html

Novità storica su Android, che dalla prossima versione abbandonerà il Java Development Kit di Oracle in favore di OpenJDK. Pare che il cambiamento sia imposto dall'alto

Click sul link per visualizzare la notizia.

Continua lo sfascio di Android :cool:
Lascio a voi quantificare la differenza qualitativa tra OpenJDK e il JDK di Oracle.

M$ ha i propri tool di sviluppo, e finalmente si capirà che non è poco.

Continua lo sfascio di Android :cool:
Lascio a voi quantificare la differenza qualitativa tra OpenJDK e il JDK di Oracle.

M$ ha i propri tool di sviluppo, e finalmente si capirà che non è poco.
Sfascio di Android perché? Qualcuno si accorgerà del cambio di API?

Io me lo chiedo sempre... ma tra tutti i linguaggi di programmazione esistenti, perchè proprio java hanno scelto?

Io credo che l'API rimarra' quella, ma cambiera' solo l'implementazione, passando dal jdk di Oracle all'OpenJDK (che e' sempre di oracle http://www.theregister.co.uk/2015/12/30/android_openjdk/ ).

Sto usando Android Studio e sinceramente e' un IDE fantastico. Sfascio di Android? :rolleyes:

Continua lo sfascio di Android :cool:
Lascio a voi quantificare la differenza qualitativa tra OpenJDK e il JDK di Oracle.

M$ ha i propri tool di sviluppo, e finalmente si capirà che non è poco.

Eh già, devono essere proprio pessime queste OpenJDK, talmente pessime che la MS ci fa addirittura una partnership per averle su Windows Azure

http://blogs.msdn.com/b/interoperability/archive/2013/07/24/microsoft-open-technologies-and-azul-systems-174-to-partner-on-an-openjdk-build-for-windows-azure.aspx
http://www.azulsystems.com/press-2013/azul-systems-releases-zulu

:Prrr:

all'università ciclicamente provavo a usarle su linux e avevo spesso problemi strani che mi cosstringevano a ritornare al jdk. Spero che ora siano state molto migliorate

Continua lo sfascio di Android :cool:
Lascio a voi quantificare la differenza qualitativa tra OpenJDK e il JDK di Oracle.

M$ ha i propri tool di sviluppo, e finalmente si capirà che non è poco.

Se ricordo bene, JDK Oracle si basa su Openjdk gia dalla versione 7 (aggiunge API e tool, ma la base è comune).
Scegliendo Openjdk semplicemente si mettono al riparo fa altre possibili cause da parte di Oracle.

Riguardo Microsoft ed i suoi tool ...
mi sa che non li usi sufficientemente a fondo perche altrimenti i loro difetti e limitazioni ti sarebbero più evidenti.

Continua lo sfascio di Android :cool:
Lascio a voi quantificare la differenza qualitativa tra OpenJDK e il JDK di Oracle.

M$ ha i propri tool di sviluppo, e finalmente si capirà che non è poco.

Sei un caso patologico direi, sto cercando di capire di chi sei il clone ma ho ancora qualche dubbio, comunque i tuoi post sono esilaranti, non mollarei mai!!! :asd:

Se ricordo bene, JDK Oracle si basa su Openjdk gia dalla versione 7 (aggiunge API e tool, ma la base è comune).
Scegliendo Openjdk semplicemente si mettono al riparo fa altre possibili cause da parte di Oracle.

Riguardo Microsoft ed i suoi tool ...
mi sa che non li usi sufficientemente a fondo perche altrimenti i loro difetti e limitazioni ti sarebbero più evidenti.

Esatto, OracleJDK altro non è che OpenJDK + qualche componente closed source

Is Oracle JDK based on OpenJDK?

Yes. Oracle JDK is based on the OpenJDK source code. In addition, it contains closed-source components. The final result is licensed under a Binary Code License.

E le migliorie vengono apportate direttamente in OpenJDK da Oracle
Is Oracle committed to OpenJDK?

Yes. Oracle remains committed to OpenJDK as the best open-source Java implementation and we will continue to improve OpenJDK and welcome external contributors.

Who contributes to OpenJDK?

Most OpenJDK contributors are engineers employed by companies like Oracle to work on OpenJDK. In addition, the OpenJDK Community has a strong showing of academics, open-source operating system distribution developers, and individual software developers with an itch to scratch. Oracle has no plans to change the contribution model and is gladly accepting new contributors. In order to learn how to contribute to OpenJDK, please see http://openjdk.java.net/contribute/.

http://openjdk.java.net/faq/

Se ricordo bene, JDK Oracle si basa su Openjdk gia dalla versione 7 (aggiunge API e tool, ma la base è comune).
Scegliendo Openjdk semplicemente si mettono al riparo fa altre possibili cause da parte di Oracle.

Anche secondo me è solo una questione di licenze, più che una motivazione tecnica.


Riguardo Microsoft ed i suoi tool ...
mi sa che non li usi sufficientemente a fondo perche altrimenti i loro difetti e limitazioni ti sarebbero più evidenti.

Io invece li uso molto, ma non ho presente particolari (gravi) difetti... al contrario di Eclipse, che finalmente è stato abbandonato in favore di Android Studio. Se poi si parla sempre di API, secondo me invece le API MS sono persino più comode e intuitive di quelle Java.

Eh già, devono essere proprio pessime queste OpenJDK, talmente pessime che la MS ci fa addirittura una partnership per averle su Windows Azure

http://blogs.msdn.com/b/interoperability/archive/2013/07/24/microsoft-open-technologies-and-azul-systems-174-to-partner-on-an-openjdk-build-for-windows-azure.aspx
http://www.azulsystems.com/press-2013/azul-systems-releases-zulu

:Prrr:

owned :D

Continua lo sfascio di Android :cool:
Lascio a voi quantificare la differenza qualitativa tra OpenJDK e il JDK di Oracle.

M$ ha i propri tool di sviluppo, e finalmente si capirà che non è poco.

Oh ohhh... Ti sei scoperto, ti è scappato un dollaro di troppo: chi usa la sigla M$ anzichè MS non può essere un fan della stessa ma caso mai uno che vuole ridicolizzarla.

Oh ohhh... Ti sei scoperto, ti è scappato un dollaro di troppo: chi usa la sigla M$ anzichè MS non può essere un fan della stessa ma caso mai uno che vuole ridicolizzarla.

Come se avesse bisogno di una mano per farlo :asd:

Direi che è una notizia positiva.

Se poi si parla sempre di API, secondo me invece le API MS sono persino più comode e intuitive di quelle Java.


:D Ti sei scordato di aggiungere: :sofico: :sofico: :sofico:

Chiunque le abbia usate a fondo sa che roba si annida nelle API di MS.
A forza di insistere con il loro "Not Invented Here" ed il voler proporre ruote triangolari al posto di quelle circolari hanno contribuito a rallentare il progresso tecnologico di almeno 20 anni ad essere buoni.
Se non ci credete, considerate come mai non ci sono più vere nuove killer application per SO Microsoft ma al massimo copie o porting di roba sviluppata altrove.
Persino quando potevano ripartire da zero con .Net se ne sono usciti con un accrocchio patetico basato su layer costruiti sulle vecchie API e dalla pessima portabilità proprio a causa di questo.

La notizia è riportata male, in realtà Google è semplicemente passata da Apache Harmony (progetto open source morto) a OpenJDK. Quindi non solo non ha abbandonato Oracle, ma gli si è avvicinata ;-), aspettando che finisca la disputa in tribunale...

l'API rimarra' quella, ma cambiera' solo l'implementazione, passando dal jdk di Oracle all'OpenJDK (che e' sempre di oracle http://www.theregister.co.uk/2015/12/30/android_openjdk/ ).
Incredibile che su un forum come hwupgrade tu sia l'unico che l'ha notato. Le api non cambiano e il processo di google contro oracle c'entra come i cavoli a merenda.

Continua lo sfascio di Android :cool:
Lascio a voi quantificare la differenza qualitativa tra OpenJDK e il JDK di Oracle.

M$ ha i propri tool di sviluppo, e finalmente si capirà che non è poco.

Il trollometro è andato a fondo scala :D
EDIT mi correggo, ho visto gli altri tuoi post, sei un fanboy MS, non era una trollata, eri serio :muro:

Sinceramente sono anni che compilo l'OS Android con l'OpenJDK al posto del Java SE JDK senza problemi, ad esclusione di dover omettere il CTS.

Tutti i miei telefoni funzionano perfettamente (Nexus 4, Xperia X8, Nexus 7 2012, Samsung Advance S) senza rallentamenti ed intoppi.

Non penso che passare "ufficialmente" al tale layer sia poi questo gran problema, anzi, la google si farà un proprio fork della libreria e sistemerà o aggiungerà nuove interfacce che probabilmente torneranno utili a tutti come l'implementazione del Bluetooth come da specifica ORACLE (e da lei mai implementata) stesso per i dispositivi seriali, etc.

Io me lo chiedo sempre... ma tra tutti i linguaggi di programmazione esistenti, perchè proprio java hanno scelto?
Masochismo autolesionista? Piattaforma open già bella e pronta da usare come base per il proprio progetto? O entrambe.
:D Ti sei scordato di aggiungere: :sofico: :sofico: :sofico:

Chiunque le abbia usate a fondo sa che roba si annida nelle API di MS.
A forza di insistere con il loro "Not Invented Here" ed il voler proporre ruote triangolari al posto di quelle circolari hanno contribuito a rallentare il progresso tecnologico di almeno 20 anni ad essere buoni.
Se non ci credete, considerate come mai non ci sono più vere nuove killer application per SO Microsoft ma al massimo copie o porting di roba sviluppata altrove.
Persino quando potevano ripartire da zero con .Net se ne sono usciti con un accrocchio patetico basato su layer costruiti sulle vecchie API e dalla pessima portabilità proprio a causa di questo.
Forse non hai mai provato a sviluppare su Android + Java e a fare lo stesso su Windows Phone + C#, per capire che differenza passa fra le due piattaforme.

Sono entrambe roba marrone, ma solo la seconda è l'equivalente della Nutella...

Forse non hai mai provato a sviluppare su Android + Java e a fare lo stesso su Windows Phone + C#, per capire che differenza passa fra le due piattaforme.

Sono entrambe roba marrone, ma solo la seconda è l'equivalente della Nutella...
Pensa che io sviluppo roba in C++ che deve essere crossplatform e deve girare su windows, windows ce ed android.
C# cerco di evitarlo il più possibile, è letteralmente il nuovo visualbasic, più semplice e facile per roba da poco o di contorno, ma da evitare come la morte se si sviluppa codice di cui si ha la proprietà o che si pensa di riutilizzare.

In questo contesto C++ non c'entra: il confronto era fra Java/Android e C#/Windows Phone, e se hai avuto modo di sviluppare per entrambi dovresti avere un giudizio abbastanza oggettivo su quale sia la piattaforma migliore.

Parlando invece soltanto di C#, non vedo quale sarebbe il problema, visto che è uno standard ECMA. Come pure buona parte del framework .NET, incluso il runtime (che di recente è diventato open source).

non appena compariranno i primi cellulari windows x86 blackberry cesserà definitivamente di esistere -> poi scompariranno anche ios e android -> poi sarà il turno della divisione hardware di microsoft -> infine se dio vuole avremo dei cellulari x86 compatibili e economici (di terze parti come è avvenuto per i pc), con windows 10, o linux, o quello che uno vuole.

In questo contesto C++ non c'entra: il confronto era fra Java/Android e C#/Windows Phone, e se hai avuto modo di sviluppare per entrambi dovresti avere un giudizio abbastanza oggettivo su quale sia la piattaforma migliore.
C'entra eccome, e nota che si parlava di API di Windows non delle sole WinRT o dell'ulteriore sottoinsieme utilizzabile con Windows Phone (che sta per sparire visto che verrà sostituito dal nuovo runtime più esteso di Windows 10 "per Arm").

Parlando invece soltanto di C#, non vedo quale sarebbe il problema, visto che è uno standard ECMA. Come pure buona parte del framework .NET, incluso il runtime (che di recente è diventato open source).

Solo che il resto della API sono roba proprietaria Microsoft, in cui spesso è stata reinventata la ruota solo ed esclusivamente per avere un maggior lock-in nei confronti degli sviluppatori.

E' anche per questo che Microsoft si è resa irrilevante agli occhi di chi fa davvero innovazione.
Va bene se ti pagano per fare l'ennesima applicazione per Windows su specifiche del cliente, ma se sviluppi roba "tua" e scegli di usare C# e di avere come unico riferimento Windows ... ti ritrovi a sprecare inutilmente un sacco di tempo ogni volta che in Microsoft decidono di semplificarSI la vita a tuo danno, senza contare la problematica portabilità al di fuori dell'ecosistema Microsoft (ed anche al suo interno).

non appena compariranno i primi cellulari windows x86 blackberry cesserà definitivamente di esistere -> poi scompariranno anche ios e android -> poi sarà il turno della divisione hardware di microsoft -> infine se dio vuole avremo dei cellulari x86 compatibili e economici (di terze parti come è avvenuto per i pc), con windows 10, o linux, o quello che uno vuole.
Beh, certo, è una conosciuta legge di mercato che per avere dispositivi economici sia indispensabile totale assenza di concorrenza. :rolleyes:

Non ho mai programmato ad oggi per Android ma il c\c++ esiste per questo os a livello pro o Java è la soluzione prestabilita

Non ho mai programmato ad oggi per Android ma il c\c++ esiste per questo os a livello pro o Java è la soluzione prestabilita

Si, si può programmare anche in C/C++ usando l'NDK (Native Development Kit) insieme all'SDK che di default supporta solo Java.
Solo che poi se si decide di rilasciare l'app su Google Play bisogna rendere disponibili versioni separate per ARM ed x86 oppure "selezionare" la versione nativa in fase avvio dell'app.

Java comunque resta la soluzione preferenziale, visto che il grosso delle API si basano sui runtime Dalvik/ART.
In genere si usa il C/C++ per la parte "non UI" o per integrare nell'app librerie scritte in C/C++ (tipo ad esempio OpenCV).

Io di solito utilizzo Qt perche "incapsula" in modo crossplatform anche la parte relativa all'UI e permette di scrivere in C/C++ pure quella parte.

C'entra eccome, e nota che si parlava di API di Windows non delle sole WinRT o dell'ulteriore sottoinsieme utilizzabile con Windows Phone
Nel tuo commento #8 hai risposto parlando di JDK, e dunque di Java, anche se alla fine hai parlato dei tool di Microsoft, ma macellatore parlava chiaramente di Android nel suo commento.

Nel tuo successivo commento, il #16, a cui ho poi risposto, rispondevi al commento di Tux89 che, pure lui, parlava di API e citava esplicitamente Java. Da questo hai poi continuato a ruota libera su Microsoft e, infine, .NET.

Ciò precisato, e considerato che non hai mai risposto direttamente alla mie precedenti affermazioni su Android/Java e Windows Phone/C# (e aggiungerei anche Microsoft Expression Blend per gestire la parte grafica della GUI: un tool a dir poco spettacolare), credo di poter assumere che tu non abbia sviluppato con entrambi e, dunque, non sei in grado di esprimere un giudizio su quale delle due piattaforme sia "migliore" per uno sviluppatore.

Più avanti parlo anche di Microsoft in generale, ma intanto mettiamo un punto sull'argomento più inerente al thread.
(che sta per sparire visto che verrà sostituito dal nuovo runtime più esteso di Windows 10 "per Arm").
A me risulta che, proprio con Windows (Phone) 10, il supporto non sia più limitato all'architettura ARM, ma sia stato esteso anche a x86 e x64.
Solo che il resto della API sono roba proprietaria Microsoft, in cui spesso è stata reinventata la ruota solo ed esclusivamente per avere un maggior lock-in nei confronti degli sviluppatori.
Dipende da cosa usi. Ci sono diversi progetti che sono basati su Mono, e dunque non ricadono nei casi che hai citato. Mi pare ci sia un progetto di un certo spessore per Linux, scritto in C# + .NET/Mono, ma adesso non ricordo il nome.
E' anche per questo che Microsoft si è resa irrilevante agli occhi di chi fa davvero innovazione.
Perdonami, ma parlando proprio di innovazione sono gli altri linguaggi/piattaforme, Java in primis, che sono rimasti al palo, e soltanto dopo parecchio tempo hanno copiato ciò che Microsoft ha reso disponibile da parecchio tempo.
Va bene se ti pagano per fare l'ennesima applicazione per Windows su specifiche del cliente, ma se sviluppi roba "tua" e scegli di usare C# e di avere come unico riferimento Windows ... ti ritrovi a sprecare inutilmente un sacco di tempo ogni volta che in Microsoft decidono di semplificarSI la vita a tuo danno,
Qui immagino che ti riferisca al passaggio da .NET 1.1 a 2.0 e successivi. Roba di parecchi anni fa. Peraltro 2.0 è per larga parte compatibile coi predecessori, per cui il cambiamento non è stato drammatico.

La cosa seccante è stata, invece, l'abbandono di Silverlight, per spingere su quello squallore di HTML5+CSS+JavaScript.
senza contare la problematica portabilità al di fuori dell'ecosistema Microsoft (ed anche al suo interno).
Mono dimostra si possano realizzare tante belle cose, visto che .NET, anche senza WPF e WCF (che sono comunque dei gioielli di tool), rimane un framework bello e molto ampio.
Non ho mai programmato ad oggi per Android ma il c\c++ esiste per questo os a livello pro o Java è la soluzione prestabilita
Se ti è possibile, evita di lavorare con l'NDK: è un inferno.

Android è già di per sé una piattaforma molto bacata e farraginosa con il framework Java, ma con C++/NDK è molto peggio.
Si, si può programmare anche in C/C++ usando l'NDK (Native Development Kit) insieme all'SDK che di default supporta solo Java.
Solo che poi se si decide di rilasciare l'app su Google Play bisogna rendere disponibili versioni separate per ARM ed x86 oppure "selezionare" la versione nativa in fase avvio dell'app.
Da un po' sono disponibili gli universal binary, per cui non serve più un apposito binario per ogni architettura supportata.

Android è già di per sé una piattaforma molto bacata e farraginosa con il framework Java, ma con C++/NDK è molto peggio.

Usando Qt Creator non è così male, basta considerare tutto il tempo risparmiato potendo riutilizzare lo stesso codice C/C++ sia per Windows che per Android e tutte le librerie già disponibili sempre in C/C++ ed è molto meglio che riscrivere tutto in Java on in C#.

Da un po' sono disponibili gli universal binary, per cui non serve più un apposito binario per ogni architettura supportata.

Allo stato attuale con l' "universal APK" non si fa altro che mettere nello stesso apk le librerie precompilate per i vari target supportati, il risultato sono degli apk di dimensioni maggiori, semmai sarebbe il caso che introducessero come estensione dell'app Google Play il runtime "universale" basato su LLVM che hanno sviluppato per Chrome
(in modo da rendere retrocompatibili con il runtime anche le vecchie versioni).

Usando Qt Creator non è così male, basta considerare tutto il tempo risparmiato potendo riutilizzare lo stesso codice C/C++ sia per Windows che per Android e tutte le librerie già disponibili sempre in C/C++ ed è molto meglio che riscrivere tutto in Java on in C#.
Assolutamente d'accordo: non ha senso riscrivere tutto quando hai tanto codice già pronto e funzionante.
Allo stato attuale con l' "universal APK" non si fa altro che mettere nello stesso apk le librerie precompilate per i vari target supportati, il risultato sono degli apk di dimensioni maggiori,
Ma dallo store non viene scaricato un apk "ad hoc" per l'architettura del dispositivo? Su questo non mi sono documentato. Sarebbe una schiocchezza immane far scaricare l'apk universale su ogni dispositivo, salvo poi usarne soltanto una parte.
semmai sarebbe il caso che introducessero come estensione dell'app Google Play il runtime "universale" basato su LLVM che hanno sviluppato per Chrome
(in modo da rendere retrocompatibili con il runtime anche le vecchie versioni).
Dubito che arriverà qualcosa del genere su Android, dopo tutto quello che hanno investito in ART.

P.S. Invece per il debugging mi aspetto cambiamenti notevoli in futuro, ma ne riparleremo quando arriverà qualche notizia.

Ma dallo store non viene scaricato un apk "ad hoc" per l'architettura del dispositivo? Su questo non mi sono documentato. Sarebbe una schiocchezza immane far scaricare l'apk universale su ogni dispositivo, salvo poi usarne soltanto una parte.

Vi sono essenzialmente due metodi.
Si può compilare un apk con gli shared object (quello che sotto windows sono le dll) compilati per le varie architetture supportate e "selezionarle" all' avvio.
Oppure si caricano su Google play più versioni che differiscono SIA come numero di versione CHE di tipo di cpu supportata.
Il secondo metodo è quello in uso da più tempo e permette di avere versioni ad hoc anche in base alla gpu ed altre informazioni sull'hardware, solo che bisogna caricare sullo store più apk compilati separatamente ecc. ecc.
In entrambi i casi l'utente non vede differenze (a parte le dimensioni dell'apk scaricato) e non deve selezionare versioni speciali o cose simili visto che nel secondo caso Play Store seleziona automaticamente l'apk migliore.