![Google responde a la denuncia sobre Android presentada por Oracle [ENG]](https://cdn.mnmstatic.net/cache/0f/a5/media_thumb_2x-link-1025318.jpeg?1417882214)
Después de que Oracle decidiera denunciar a Google, debido a que su sistema operativo Android presuntamente viola algunas de las patentes que Oracle mantiene sobre Java, Google ha decidido responder: "Estamos decepcionados que Oracle haya decidido atacar tanto a Google como a la comunidad Java de código abierto con una demanda sin base, la comunidad Java de código abierto va mas allá de cualquier corporación"... Relacionada: Oracle demanda a Google por infringir copyrights de Java en Android
Comentarios
Oracle a que ha venido ¿a tocar los huevos?
Oracle mata OpenSolaris
Oracle mata OpenSolaris
phoronix.com#7 Porque la implementación de Java de IBM es 100% compatible con Java.
¿SCO? ¿Estás loco?
Es Google quien atacó a Java y no al revés.
Java siempre ha sido libre y han existido implementaciones gratuitas tanto de java como de Java2 Enterprise Edition. La única condición que Sun (ahora Oracle) ha impuesto siempre es que se mantenga la compatibilidad 100% de java. Microsoft intentó atacar a Java haciendo una versión incompatible y acabó teniendo que pagar 1600 millones de dólares a Sun en indemnizaciones. Google ha hecho una versión incompatible de Java y tendrá que ser un juez quien dictamine hasta que punto se ha saltado las licencias o si es legal o no su actuación.
#8 Jua jua jua jua, que es 100% compatible con Java?, monta un JBOSS bajo la JVM de IBM que corra una aplicación web cualquiera que utilice java faces de Sun y luego me cuentas, o que acceda a un keystore utilizando la implementación de Sun a ver cuantos petes te encuentras.
Ahora el caso contrario, prueba a correr una aplicación hecha con Rational Architect de IBM (es un eclipse modificado que corre la versión de JVM de IBM) con la jvm de Sun, a ver cuanto código tienes que modificar para que funcione.
#11 Maldito Websphere de los Coj$nes y maldita implementación propia de Jsf!!!
#11 De hecho, el clásico OAS (Oracle Application Server) es incompatible con muchas librerías libres de Java (por ejemplo Axis y algunas librerías de manejo de XML).
#8 Si hubieras leido las patentes sabrias que la denuncia no tienen absolutamente nada que ver con que la implementación de java de google sea diferente e incompatible con la de SUN.
#14 ¿Me puedes pasar un link a las patentes?, no las veo por la noticia y me gustaría leerlas. Gracias, veo que te has adelantado.
#14 No, pero las especificaciones de Java autorizan a usar esas patentes a quien las cumpla (cualquiera puede hacer una implementación de java sin pagar). Así que Google infringe las patentes al no cumplir las especificaciones.
#8 Son relativas a Android, Dalvik y su entorno de desarrollo.
* http://www.google.com/patents/about?id=dyQGAAAAEBAJ&dq=6,125,447: Protection domains to provide security in a computer system; Li Gong
* http://www.google.com/patents/about?id=G1YGAAAAEBAJ&dq=6,192,476: Controlling access to a resource; Li Gong
* http://www.google.com/patents/about?id=TzsPAAAAEBAJ&dq=5,966,702: Method and apparatus for pre-processing and packaging class files; Nedim Fresko, Richard Tuck
* http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&d=PTXT&s1=7,426,720&OS=7,426,720&RS=7,426,720: System and method for dynamic preloading of classes through memory space cloning of a master runtime system process; Nedim Fresko
* http://www.google.com/patents/about?id=8xkPAAAAEBAJ&dq=RE38,104: Method and apparatus for resolving data references in generated code; James Gosling
* http://www.google.com/patents/about?id=U-4UAAAAEBAJ&dq=6,910,205: Interpreting functions utilizing a hybrid of virtual and native machine instructions; Lars Bak, Robert Griesemer
* http://www.google.com/patents/about?id=mEwEAAAAEBAJ&dq=6,061,520: Method and system for performing static initialization; Frank Yellin, Richard Tuck
¿Qué será lo siguiente? ¿MySQL?
#2 Es un segredo a voces...
Me parece muy bien esta demanda. Así, igual Google se lo piensa dos veces y ELIMINA Java de Android (todos a pasarse a C/C++!!!). ¿Cómo es posible que una plataforma móvil lleve Java? Nunca lo he comprendido. Máquinas virtuales en sistemas donde prima la eficiencia energética y la economía de recursos… es de locos.
Y si de paso sirve para que Java desaparezca de más sitios, pues mejor. La indefensión e intranquilidad que estarán sintiendo muchos sistemas que lleven Java debe ser enorme, tanto como para replantearse las cosas.
#17 Porque el tiempo de implementación crecería enormemente, no puedes comparar el lenguaje con más clases del mundo con C++, puesto que aunque C++ es mucho más rápido y eficiente el tiempo de desarrollo encarecería enormemente el producto, ya no hablemos de C donde los objetos son inexistentes y no te queda otra que hacer chapucillas con structs para simular algo parecido a una clase.
Luego a eso le sumas problemas de compatibilidad, imagínate que tienes que compilar el programa x en C para cada una de las arquitecturas, los lenguajes interpretados o aquellos que son semi compilados (como Java) basan su compatibilidad en un interprete (como es la JVM) por lo que la única cosa que necesitas (en teoría) que este compilada para esa arquitectura es la JVM.
De todas formas la implementación de JavaME no tiene nada que ver con la JVM estándar, por lo que esos problemas de rendimiento a los que aludes no son tan grandes como pretendes hacer ver.
Piensa una cosa, Java es el lenguaje de programación más utilizado.
#18 ya no hablemos de C donde los objetos son inexistentes y no te queda otra que hacer chapucillas con structs para simular algo parecido a una clase.
http://en.wikipedia.org/wiki/GObject
#23 Bonita respuesta pero errónea, C por si solo no está orientado a objetos, es como si creo una clase Java para hacer herencia múltiple como en C++ y digo que Java tiene herencia múltiple.
#28 No insinuaba que C fuera orientado a objetos, insinuaba que "no te queda más que hacer chapucillas con structs" era incorrecto.
Para #28 y #23. Se puede programar orientado a objetos en Ansi C, el codigo no sería tan elegante como el producido en C++ o Java pero poderse se puede. En el paradigma de la orientación a objetos es mucho más importante la metodología que las herramientas que pueda incorporar un lenguaje de programación orientado a objetos. Si el código resultante en Ansi C es una 'chapuza' o no solo depende de la pericia del programador.
#44 Dime como logras el encapsulamiento programando en Ansi C.
bajo tu criterio se podria programar COBOL orientado a objetos
Para #45.
Para lograr el encapsulamiento programando en Ansi C para empezar no hay que intentar leerse el código fuente de una clase y utilizar solo sus funciones definidas en la documentación como 'públicas' a modo de métodos de clase. Esto hay que aplicarlo si la clase la ha escrito otra persona para respetar el requisito de encapsulamiento que no es nativamente soportado por Ansi C.
Una clase podemos definirla con un Struct, y creamos los objetos asignándole a cada nuevo objeto su correspondiente espacio en memoria con el tamaño en bytes (sizeof) del la clase definida por el Struct. No hay que olvidar liberar memoria cada vez que un objeto se convierte en innecesario.
En Ansi C puedes hacer practicamente lo que te dé la gana, o no hacerlo; por lo que la única forma de 'protejer' a una clase de la posibilidad de ser modificada desde fuera del propio objeto (o de la propia clase) es manipularla voluntariamente solo desde sus métodos (que serán funciones que manipulan nuestros objetos creados con Struct) desde nuestro programa.
Conozco el COBOL de la época del MsDos y no me he sentido tentado de probar versiones actuales. COBOL más que un lenguaje de programación parece un plantilla de programación, al menos el Cobol RM85 era asi. Ansi C es mucho mas indicado para programar orientado a objetos que COBOL.
El manejo de punteros a memoria y el acceso y toqueteo a bajo nivel es cosa de C.
#46 joer, el primer programa "orientado a objetos" que ví, estaba hecho en C.
Era un libro sobre la programación del puerto serie (años 90), y el paisano iba explicando como estructurarlo todo, con unos struct conteniendo los punteros a las funciones/metodos y los datos asociados, etc etc, para que quedase todo bien "en forma de objetos".
Me dejó impresionado.
#23 Otro que no se enteró que los primeros compiladores de c++ convertían el código c++ en puro c como paso inicial. GObject es una implementación del paradigma de computación mediante objetos escrito en c, no v eo que deje de tener validez alguna. Ahora bien se te gusta usar un lenguaje con tipado para objetos es otra cosa, pero una limitación tuya no es motivo de llamar chapuza a una implementación de objetos. De hecho si usas vala para programar ya me dirás que diferencia tienes con respecto a hacerlo con c++ antes de que el mismo que inició el desarrollo del lenguaje d creara en su día el primer compilador directo de c++.
En serio, ¿tan difícil es buscar información en internet? Cuando digo buscar pienso también a su vez en investigar pero parece que ahora toda la información al respecto de una cosa se reduce a la primera página de google.
#29 Creo que tu comentario va por mi. He sido yo el que ha dicho lo de las chapuzillas con structs.
#31 Cierto, empecé a escribir una vez leído todo en vez de dar a reply y al buscar hacia arriba vi la cita y no el original. Gracias por el aviso aunque ya no puedo editarlo. Lo dicho, en c se pueden hacer implementaciones para tratar objetos, que sea una chapuza o no depende de la implementación, GObject es bastante interesante como implementación de objetos en C, con sus más o sus menos pero igual que todo lenguaje hecho orientado a objetos directamente, todos ellos también tienen sus más y sus menos.
#23, ni caso iba en referencia a #18 el mismo a quién habías respondido.
#18 tu ultima oracion demuestra que eres un fan boy de java.
Para #17. Tienes razón en que dispositivos moviles tan limitados en capacidades como los teléfonos deberian ser programados en C y C++ para optimizar a tope código para la CPU y ahorrar al máximo recursos de memoria, pero una tecnología como Java tiene mucho sentido en el mundo de los PCs donde no faltan recursos para correr aplicaciones 'poco' exigentes o ligeras (y no tan ligeras) corriendo sobre la máquina virtual de java.
Google decidió usar Java porque es uno de los lenguajes de programación más usados en el mundo. Fue una estrategia para captar a muchos programadores y facilitarles la programación en Android, haciendo que no tuviesen --muchos de ellos-- que cambiar de lenguaje de programación. Pues ha sido un gran fallo.
Han incluido una VM en un dispositivo móvil, por lo tanto el terminal o consume más batería, o va más lento, o ambas. Y ha sido un error usar Java, aunque Android se esté comiendo el mercado. Ha sido un error porque Apple con la porquería de lenguaje que es ObjectiveC ha conseguido crear una base muy grande de desarrolladores. No sólo eso, sino que aparte del lenguaje, ¡sólo puedes programar para iOS con un Mac!. El aspecto positivo es que el lenguaje ObjectiveC compilado es muy veloz.
Lo que tendría que hacer Google es olvidarse de Java y potenciar Python para Android. No va a ser tan veloz como una compilación en C, pero es un lenguaje brutal, ultra-flexible y muy productivo. Teniendo a Guido no les debería costar mucho...
#26 Si nos centramos exclusivamente en el rendimiento por mi experiencia con ambos lenguajes Python es bastante más lento que Java sobretodo en tema de cálculos para gráficos (y estoy hablando en 2D que es lo que he tocado, en 3D no me quiero ni imaginar como sería), así que no tendría sentido pasarse a Python por eso mismo que criticas.
Por otra parte Dalvik hasta donde yo sé tiene JIT como muchas otras máquinas virtuales así que acabas ejecutando código nativo de las partes más críticas, y si aún así no estás contento puedes usar directamente el NDK y escribir en C/C++ y optimizar tu mismo lo que creas oportuno. Por opciones no será.
Luego habría que ver cuan más lento és, o cuanto más consume Dalvik que Objective-C, si es que es así, porque este último tampoco es directamente C++, pero como no lo he tocado para nada no puedo opinar, pero las aplicaciones Android no me parece viaulmente mucho más lentas que las del iPhone.
#26 En maemo para nokia y el meego corren programas en c c++, puedes instalar la jvm para correr java y los front-ends son casi todos en python con qt. Python viene preinstalado (npi si en android o iphone corre) Incluso los juegos en flash suelen correr sin problemas!
Por qué empeñarse en hacer cosas restringidas cuando puedes ejecutarlo todo!
Respecto a python y el 3d sino tengo mal entendido es el lenguaje de script que usan casi todas las aplicaciones profesionales de diseño 3d. (hablo sin saber demasiado, corregidme si me euivoco) y lo que hace es llamar a las apis más optimizadas que usan las aplicacione.
Yo no quiero un android! ni un iphone!
Pero quizá nokia esté perdiendo la batalla del marketing... O tenga un as bajo la manga... no sé.
Pero estas guerras coporativas son graciosas eso sí.
#42 Dudo que el kernel de esas aplicaciones gráficas esté escrito en Python. Yo supongo que se usará para pequeños scripts. Al menos los videojuegos usan este enfoque para diseñar la lógica de juego, solo que en vez de Python se suele usar más Lua.
#49 Claro. Python es lenguaje de script, por lo que entiendo (no sé lo suficiente, ni me dedico a ello :-)), pero es con el que se pueden controlar un montón de efectos, filtros, animaciones, delegando los procesos más costosos a otras aplicaciones de más bajo nivel y menor consumo de recursos, claro.
Por poner un ejemplo tonto, si dibujas una cafetera, las funciones de cálculo vectorial estarán programadas a saber cómo y en qué lenguaje (intuyo c++). Si después quieres cambiar color dinámicamente, mover la cámara, de la cafetera, etc... recurriras a python. Creo que Maya, 3ds MAX, Blender y RealFlow lo usan como lenguaje de script.
Hablo sin saber, ojo!! Si alguien sabe que me diga!. Lo sé por un chico que conozco que es diseñador y trabaja con esos programas...
#26 Soy un gran aficionado a Python, de hecho me gusta más que Java, pero siento decirte que Python es más lento. La inicialización de la máquina virtual Java es un proceso muy costoso, por eso cuando iniciamos aplicaciones que usan Java son superlentas, pero una vez iniciada, en prácticamente todos los aspectos supera a Python. Por eso para hacer funcionar un script que no va a durar mucho tiempo, te va a ser mejor usar Python, Perl o Bash que Java.
Antes que meter Python, metía C++ y con un montón de librerías que ayuden al programador, como hace Nokia con Qt.
Siempre nos quedará PROGRESS v6
Ya que veo tanto programador por aquí... ¿a vosotros no os pasa como a mí, que adoráis Java como lenguaje pero lo odiáis como implementación, y al revés con C++? ¿No ha habido nadie que haya hecho una implementación de Java que no compile a bytecode?
Desde mi punto de vista, me da la impresion que del momento que Oracle se hizo con Sun, lo único que busca es quitarse de encima todo lo que es open source. Y hacer la empresa lo mas parecido al sistema de negocio de microsoft.
Java dentro de poco, al igual que openoffice y otras herramientas de Oracle, las mantendrà solo la comunidad ... a no ser que alguna empresa más liberal las compre antes de que desaparezcan.
Muy atentos a la opinión de Miguel de Icaza (En inglés) http://tirania.org/blog/archive/2010/Aug-13.html Está enlazado en el artículo. Deja bastante claro de qué trata el asunto. Coincide con lo expuesto en Oracle demanda a Google por infringir copyrights de Java en Android/c8#c-8 pero explica muy bien el por qué de las decisiones de cada parte, al parecer motivadas por cobros/pagos de licencias.
Vale que oracle sea una empresa y Sun otra, que la haya comprado y tal, pero estas cosas deberían de regularse de algún modo..... no debería poderse comprar una empresa, hacer loq ue quieras con ella, cuando tienes una comunidad detras dependiendo de esa empresa, y hacer cambios que dejen a la gente tirados (vease opensolaris) o empezar a cambiar drasticamente tu política.......
En fin, estos de Oracle son mucho de "Es mi caballo y me lo follo cuando quiero"... ojalá no hubieran comprado Sun....
Esto es voy a ver si denuncio a Google a ver si cae algo. Putas patentes
Oracle avisa. Hay que dejar de utilizar Java.
¿Algún experto en el tema me podría explicar qué riesgo supone para los usuarios y desarrolladores que Oracle comprara MySQL? ¿Que fuera de pago? Gracias de hantebraso antemano.
Oracle está matando Openoffice...
Oracle es que compró Sun recientemente jejeje
Anda!, pero java no era super super libre, no como .NET en el que microsoft te podía demandar en cualquier momento?
En todos lados cuecen habas.
#4 Lo es... en Europa, donde no son válidas las patentes de software. Lo que sucede aquí es que Oracle a base de patentes quiere el trozo de pastel de Android que Sun no pudo conseguir, pero estoy seguro que al final tendrán que retirarse.
#4 Creo que Google la ha "cagado".
El permiso para java "super libre" tenía una clausula. Esta libertad era otorgada sólamente para versiones totalmente compatibles con la implementación de Java.
Google, al igual que intentase Microsoft años atrás realizó una versión incompatible de Java para Android. De hecho, Google no tiene permiso para utilizar la palabra "Java" en sus productos. Por tanto todas las libertades concedidas por Sun (ahora Oracle) no son aplicables. Sun lo dejó bien claro, nada de versiones incompatibles de Java, por que entonces se pierde toda la ventaja de Java, es decir poder ejecutarse sin cambios en cualquier plataforma.
En cierto modo me alegro, porque los hipócritas de Google con Android lo que han hecho ha sido mezclar Linux con Java haciendo una versión que no es compatible ni con Linux ni con Java.
Qué diferencia por ejemplo con la forma de actuar de Nokia. Nokia tiene 2 sistemas operativos, uno basado en Linux (Meego) y otro propio (Symbiam). Tango Meego como Symbiam pueden programarse con la misma librería (QT). Además QT nó solo es compatible con Meego y Symbiam sino también con Windows o MacOSX o UNIX. Nokia también permite programar los móviles utilizando Java, una versión compatible de Java, y a pesar de que tiene un mercado mucho mayor que Android nunca ha tenido ningún litigio con Sun u Oracle.
Google es responsable de sus actos. No intentemos darle la vuelta a la tortilla.
#6 ¿ Entonces por que no denuncian a IBM cuando lleva lustros utilizando su propia implementación de Java ?
Sinceramente esto huele a SCO.
#6 Filing patent suits was never in Sun’s genetic code
#c-6" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1025318/order/6">#6, desde el cariño: Google en ningún momento indica que utiliza la plataforma Java. En realidad solo utiliza el lenguaje de programación. El API, por ejemplo, corresponde a un subconjunto de una implementación open source (creo recordar que del proyecto Harmony de Apache). La máquina virtual NO es un jvm (es una Dalvik VM), ni comparte los mismos bytecodes. Y hasta donde yo sé, no hay nada que impida a quien quiera hacerlo usar la sintaxis java. Microsoft, por ejemplo, lo hace con J#.
Evidentemente la idea es facilitar la migración de programadores SE/EE a entornos Android. Pero esto es una jugada legal y que a mi personalmente me facilita muchísimo la curva de aprendizaje.
Y en realidad el proyecto Android, si fuese una implementación para escritorio, sí podría usar libremente la base de código de Sun. Todo lo anterior viene motivado simplemente porque Sun reservó los derechos para implementaciones que corriesen sobre dispositivos móviles porque consideraron que allí todavía tenía sentido comercial mantener ese mercado como coto privado.
Saludos...
#24 Por lo que he leido, no es tan simple. En el desarrollo de Dalvik VM y Android Google contrato a varios ex-ingenieros de Sun que previamente habían trabajado en la máquina virtual de java. Hasta allí todo legal. El problema que tiene Google es que al desarrollar Dalvik perdió la compatibilidad con Java y entonces es cuando entran en juego las clausulas que Sun puso al liberar Java. La libertad y derechos para utilizar la tecnologia estaba condicionada a mantener la compatibilidad con Java. Al romper la compatibilidad Google pierde los derechos para utilizarla libremente. Y parece claro que la está utilizando si tenemos en cuenta que sus desarrolladores son ex-ingenieros de Sun que trabajaron durante años en Sun Microsystem desarrollando Java.
Saludos, igualmente
#24 Efectivamente. Que yo sepa excepto que el lenguaje de programación es Java (y seguramente se podrían crear compiladores para cualquier otro, si no me equivoco creo que se puede usar C para crear programas de Android), por lo demás Android no tiene nada que ver con el Java de Sun/Oracle, ni su máquina virtual ni sus ejecutables ni sus librerías.
#4 No se si sabes de que va la película, pero los problemas están viniendo desde que Oracle compró Sun, propietaria de Java.