Web - SOAP/XML vs REST/JSON

Otro documento que me he encontrado revisando material antiguo, esta vez comparando algunas tecnologías clave en los servicios web.

1 - Overview

In this document we will talk about two of the systems to work with Web Services that nowadays are fighting for domain the market in this area, which is one of the most important in the computing.

SOAP (Simple Object Access Protocol) is a protocol which defines how two objects in different processes can communicate data between them. This data is formatted in XML (eXtensible Markup Languaje) which is (as its own name indicates) a markup language derived from SGML (Standard Generalized Markup Language). It was developed by W3C (World Wide Web Consortium) looking for simplicity, generality and usability over the Internet. For the transmission of this XML messages usually relies on HTTP (HyperText Transfer Protocol). SOAP is under the control of W3C.

The typical aspect of a SOAP message is like you can see in the next image, the entire document is written in XML and it consists in a SOAPEnvelope which contains the optional SOAPHeader and the mandatory SOAPBody. The SOAPHeader allow us to provide extended information about the message like authentication, transaction management and payments. Inside the SOAPBody, on each body entry is where the data specific to the actual method of the Web Service request call is stored, such as method name and parameters and/or return values for the method invocation. The structure of the data inside the SOAPBody is organized according to the representation given by the WSDL file in the part where defines the message. The SOAPFault is used to inform about error or status.

Example of SOAP/XML

REST (REpresentational State Transfer) is not a protocol (as SOAP is), is a software architecture technique for distributed systems like WWW (World Wide Web). The term was originated in a doctoral dissertation by Roy Fielding in 2000, one of the authors of HTTP. REST can be used with XML but is more used with JSON due the simplicity of this last which match better with the basic idea of REST.

This idea is take advantage of what is already there, this means take advantage of the web itself. For REST there are only resources which are identified by only one and unique URL (or URI Uniform Resource Identifier), these resources can have many representations and the client can ask for each representation of the resource depending of the way he needs those resources.

One of those representations can be JSON, an acronym of JavaScript Object Notation, created by Douglas Crockford is a light format to interchange data. The simplicity of JSON has made it really used, as an alternative to XML in AJAX and in many others spaces like Web Services.

In the next image we can see the use of the REST architecture using HTTP for the interaction between client and server in a system for weather information. Besides we are using JSON as the representation for the resource. In this case we want to know the temperature in Paris in ºC, so we send the request to the weather resource which gives the representation according to our petition. Note the structure of the URI for this resource using only slash and names without any type of typical parameters like weather?city=Paris&units=C, which is not a clean URL and it is not according to the REST style. The information of parameters is stored inside the HTTP request (and response) and the MIME - types are used to inform of what representation are we using for the information.

Example of REST/JSON

2 - Discussion

2.1. Proxy Servers (Web intermediaries)

For REST there can be intermediaries between clients and resources to support different kinds of elements like performance or security. In SOAP it is almost necessary define a proxy which help us to hide the construction and parsing details of the web service within this proxy. This way we don’t have to manually construct the message which it will be sent to the Web Service, or parse it when we receive it, saving time coding and possible errors, all this behavior will be encapsulated in the proxy class.

2.2. Transitioning state in a client application

Respect of the states of a client application, REST is designed to be exactly a way for the user (the browser) to progress between different states depending of what the user choose to be his representation of the resource he wants to see. This progression through states is usually done by the selection of links by the user. In SOAP there is no this type of transitions, mainly because it is not an architectural style, its only concerning is the transfer of information between the client and the server and the way this has to be done.

2.3. Caching (i.e., performance)

In REST all the responses has to be capable of being labeled as cacheable or non-cacheable, this helps to improve network efficiency avoiding to reload a resource which has been already requested. Also the information transmitted is less than in SOAP, in SOAP even with only one element to transmit it has to be created a complex WSDL file and also the SOAP message which generates an overload if you only need to transmit simple elements. This is one of the reasons to use REST instead of SOAP if you only need to transmit small quantity of information.

2.4. Web evolution (semantic Web)

In terms of the famous semantic Web, REST has advantage in some way because it uses the web as it should be used, this means using what is already created and not creating new things to support operations that they are already there. We can talk here about the verbs of the HTTP protocol like GET, POST, PUT, DELETE, etc. A lot of applications and systems base their work only in the use of the GET verb, and the adding of parameters to the URL (violating the principle of “any resource is referenced by only one URL”) which makes more complicated understand where you are and what is doing the webpage you are visiting. But if you use these verbs in the correct way, and take advantage of things like the MIME - type to know what you are transmitting, and take care of use “clean urls” the web will be as it was meant to be, and it helps to make the utopic (at least for me) idea of semantic web more close to these days. And all of this will make the web for the user much more transparent, which at the end is the objective of any programmer, make the user believes that you are not there.

2.5. Generic interface (versus custom interface)

The interface which REST use can’t be more generic, it is based in the verbs of HTTP GET, POST, PUT, DELETE, HEAD, etc. which any browser is capable of manage. For SOAP is based in the use of WSDL files which tell us how we have to interact with the Web Service in terms of how to build the proxy, SOAP message and where we have to send this message helping us of the proxy.

2.6. Interoperability

With SOAP you have complete interoperability always you have access to the WSDL file and a system which was able to process XML files. Also it is a highly used standard which a lot of companies use in their software development so the probabilities to find some company which uses it and have information about the Web Service which implements are very high. For REST is not so sure because is not so standardized which makes that you could find a Web Service and you didn’t know how to use it, which is a huge problem because if you don’t know that, it means that you can’t use that Web Service correctly from the beginning and you will have to spend time figuring out the way that it works to do a correct use of it, time that you can spend working in your own work.

2.7. Processing the payload

The processing of the payload in SOAP / XML is heavier than in REST / JSON, because what it is processed is at the end a document XML, and is more difficult to process than a document written in JSON, so in these terms of processing the union between REST and JSON wins. Besides the information transmitted in SOAP has more elements which are not information themselves, only are information of control to can process the SOAP message, I am talking about the elements I mentioned in the introduction of this document like SOAPEnvelope, SOAPHeader, SOAPBody, etc.

2.8. Recommendations

The main recommendation would be that use the technology which would be better for the system you are developing, you have to know when choose SOAP / XML and when choose REST / JSON. If you need to transfer a really big amount of data and need this data completely structured and organized and also need tools and elements to have controlled all the time the application and not only when this was finished, also when you were testing and during the development process, you should go for SOAP. But if you don’t need so much background and your application is simpler without the need of that completely control you should go for REST.

2.9. Who uses what in the real-world

SOAP is more generalized since it has been in the market as a technology more time than REST, that does not mean that it was created a long time before REST, because the origins of REST as I said in the introduction are in the doctoral dissertation of Roy Fielding in 2000, and XML-RPC which is based SOAP is from 1998, but REST has not been used as it has been used nowadays until few years ago, so SOAP has more advantage than REST in this aspect. Anyway the simplicity of REST is doing each day that more developers and enterprises choose it as the way to create their software, relying in its transparency instead the “complicated” and overloaded SOAP way.

3 - Opinion

After work with both technologies I have to say that do this work with the SOAP / XML way was easier, it is not exactly because SOAP or XML were easier technologies, it is because the tools to work with them are really more advanced and it was so easy as create a java class which managed the logic of the Web Service and edit the client version to get something more user friendly than the default client generated by Eclipse (in this case the IDE that I used).

To find the way to get working with the REST / JSON application was a really more complicated work. Before know about the tutorial of REST in Moodle I started to work with a java library called RESTlet, which offers APIs for different technologies (Android, JEE, JSE, GAE, GWT, etc.), but it was really difficult find examples of its use and particularly examples based on the use of JSON as interchange format, so I decided to look for other way and after read about the tutorial in Moodle I started to used Jersey, a library for JAVA which is an implementation of JAX-RS (The Java API for RESTful Web Services). It uses annotations to define the REST elements in the Java classes. Also the JAX-RS specification supports the creation of XML and JSON using the Java Architecture for XML Binding (JAXB).

So it has almost all I needed, but even with that, understand the way REST works was hard because I am not used to use the kind of things REST is based, the use of the “clean urls” without explicit parameters using the interrogation symbol, or the concept of resource and representations of that resource, so I had to read and investigate a lot to understand the concept before start to do any code in order to avoid do useless work and even with that I lost some time trying to do some applications examples with RESTlest and Jersey, but I think it was not a completely waste of time because it helps me to get experience with the REST style.

But leaving my personal experience with both technologies behind I have to say that REST is really interesting and really simple, and comparing the amount of information transmitted and the work that Eclipse automatically does in SOAP, I am not so sure that it was easier work with SOAP if you don’t have tools to create the WSDL file or the classes to contact with the Web Service, off course you can learn to do that,, and do it perfectly, without any errors (what is difficult), but even knowing how to do it, how to build those classes, it’s a time that you can use for do other things more important and not mechanical code, that’s why is so important have the correct tools to work with SOAP, to avoid the wasting of time which is create all that extra code, a workload that could be done for a machine automatically.

4 - Conclusion

To summarize it happens something similar to the fight XML - JSON, SOAP has behind it a lot of more support that REST, more tools and more standardized systems to work with it, but despite all of that, the simplicity of REST makes it a really important alternative when you don’t need all the background things you have to define to put to work a Web Service based on SOAP.

So if you need simplicity use REST but that same simplicity will make that at least for now, tasks like testing will be harder than in SOAP, which is a technology much more standardized and expanded and that has more support and tools to work with it.

Finally the next years the Web Services and all the things in relation with the Web itself like the Cloud Computing are going to keep rising and they are going to be one of the more important sectors in the computing world because for the user is easier and for the enterprises are cheaper. So in a near future we will see probably the increment of this type of technologies in decrement of the traditional ways to build software (in fact it is actually happening).

5 - Bibliography

• http://en.wikipedia.org/wiki/Representational_State_Transfer
• http://es.wikipedia.org/wiki/Simple_Object_Access_Protocol
• http://blog.movilforum.com/apis-seguimos-con-el-rest-vs-soap/
• http://www.slideshare.net/kaniskamandal/rest-with-json-vs-soap-with-xml
• http://stackoverflow.com/questions/8599833/how-soap-and-rest-work-with-xml-json-response
• http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/
• https://devcentral.f5.com/blogs/us/soap-vs-rest-the-war-between-simplicity-and-standards
• http://itenterprisearchitect.blogspot.ie/2010/09/rest-vs-soap-web-service.html
• http://www.skill-guru.com/blog/2010/11/02/goodbye-soap-welcome-json-rest/
• REST with Java (JAX-RS) using Jersey - Tutorial

Y eso es todo, bastante completo, espero que os resulte interesante!

Un saludo!

Web: XML vs JSON

Tuve que hacer un documento en inglés sobre las características de XML y JSON hace algún tiempo, y me parece que quedó bastante bien, así que os lo dejo por aquí, cuando tenga algo de tiempo planeo "retraducirlo" al español pero por ahora os dejo el original.

Overview

In this document we show the differences and similarity of two of the most important formats to interchange information.

XML (eXtensible Markup Languaje) is a markup language derived from SGML (Standard Generalized Markup Language). It was developed by W3C (World Wide Web Consortium) looking for simplicity, generality and usability over the Internet. In the next code fragment we can see an example of how XML represents information.

 
  Bisbal
  Buleria
  10/05/2010
 

Example XML

JSON, an acronym of JavaScript Object Notation, created by Douglas Crockford is a light format to interchange data. The simplicity of JSON has made it really used, as an alternative to XML in AJAX. We show now the same information than in the previous code block but using JSON instead of XML.

{
    "albums": {
        "album": [
            {
                "artist": "art",
                "title": "GG",
                "date": "21/02/2010"
            }
        ]
    }
}

Example JSON

Discussion

Both are ways to represent information, but the way JSON uses is easier to understand at first sight than XML. Even with the use of squiggles, squares, colons and commas of JSON makes the writing of JSON files quicker than the XML files.

Extensibility

One of the differences is the extensibility, with XML (as its name shows) you can create new elements easily and represent arbitrary data structures, with JSON this is not possible, but is not exactly a weak point, because JSON does not search that, it is not a document markup language so it doesn’t need it.

Simplicity

Speaking about simplicity, JSON is simpler than XML because has a smaller grammar and the mapping of the XML basic tree to the types of the programming languages and databases could be difficult, because it was not the initial objective of XML. Sometimes the size of a JSON file could be greater than a XML file but its point is that represents better data structures and requires less codification and processing. Also has things in common, both are human readable and self-describing so any person can read a file and understand it in some way and the values has always a name (except arrays in JSON).

Data interchange

The eval() procedure of JavaScript allows a really easy way to process JSON data, but has some security problems. In general JSON needs much less specialized software than XML, or even does not need it at all, like JavaScript or Python, where the JSON notation is built into the language, in other cases you need third-party packages to support JSON, but there are a lot and they are rising each day. For XML the analyzer is a standard component, so it does not necessary create an specific analyzer for each XML version.

Interoperability

In terms of interoperability both of them offer good results making easier use the information inside the files to facilitate the communication between systems. JSON is used typically in works where the size of the data interchanges between client and server is highly important when the origin of the data is secure and where it is not important the absence of XSLT processing to manipulate the client data.

Openness

About openness JSON is more open than XML, because XML has behind it the World Wide Web Consortium, which makes do changes much more complicated and slow. In some way this is better because the W3C is a really big corporation which helps to XML keeps its presence in the world. Due to this background support there are a lot of use of XML and many developer tools to work with it, not only as an interchange format, also as an document format.

But despite of all these differences and similarities, it is frequent find JSON and XML in the same application, they are not always fighting each other to win. For example, if you have a client application using Google Maps data and also meteorology data in SOAP, these two elements make necessary use both formats (JSON and XML respectively).

Opinion

In my opinion, I think when you need to describe an information XML is clearer to read and easier to structure than if you start with JSON, and it is more difficult to make a mistake writing XML code than JSON because all the extra characters JSON uses. Despite the fact in some way JSON is simpler than XML, but for me I am more comfortable using XML. Besides in a really big hierarchical file will be more confusing in JSON than in XML (at least for me).

I think I feel better using XML than JSON because I am more used to see and write HTML (Hyper Text Markup Language) (remind HTML is based on SGML too) and I know how to manage it due to all the time I have been developing web applications. I have used JSON too but not as much as HTML, and usually only because I have been forced to use it due to the characteristics of the applications I was working.
But I recognize that JSON is less heavy to process because is simpler than XML and speaking of interchange of data could be a better option than XML.

Conclusion

To summarize both languages are really good and powerful and you need to know when you have to use XML or JSON, and know how to use them, because you never know when you can find out that the application you are developing has to connect with another that use other type of format different than you are using.

So if you need only transfer data you should use JSON but if you need transfer documents XML will suit it better.

Anyway XML is still more used than JSON but the latter is quickly growing.

Pues eso es todo el trabajo, iré añadiendo algunos más que tengo que me parecen interesantes!

Un saludo!

Docs que molan: TPB AFK

Bajo este título en apariencia tan críptico (no tanto si estas en el mundillo de Internet) se encuentra un documental que desconocía, y que me ha enganchado.

Muchos conoceréis el famoso sitio web The Pirate Bay, punto de referencia para la obtención de torrents, esos archivitos que nos dan acceso a esa preciosa red P2P que es BitTorrent, y que tras la caída de megaupload y en el fondo el paso de la descarga directa a un segundo plano (al menos para mi), se ha hecho de nuevo con el corazón de muchos.

El documental cuenta la historia detrás del mayor sitio de "compartición" de archivos del mundo, de sus 3 creadores, Gottfrid Svartholm, Fredrik Neij y Peter Sunde (unos personajes sin duda, el más normalico es Peter pero aún así), y del juicio y las acciones que la industria y la justicia sueca y norteamericana promovieron contra ellos para tirar abajo al barco pirata.

Muy interesante y bastante ameno, ¡Recomendado 100%!, os lo dejo por youtube, y también la página web oficial por si os quedáis con ganas de más.



Un saludo!

Milenio3 - El hombre quemado

Siempre he sido seguidor de Cuarto Milenio, pero a su programa hermano, Milenio3, como suele decir el gran Iker Jiménez, lo tenía bastante abandonado, seguidor más de La rosa de los vientos, pero desde que el gran Juan Antonio Cebrián paso a mejor vida no era lo mismo, así que estaba perdido en esas madrugadas...

...pero me animé a escuchar Milenio3, y se sigue sintiendo esa magia del misterio y lo desconocido a través de las ondas de radio, pero no estoy aquí hoy para hablar del Mundo Milenario, que tendré que hacerlo, sino de una coña relacionada con él, que desconocía hasta hoy mismo, y que es pa partirse.

Primero os dejo donde se descubre el misterioso caso de El hombre de la máscara de chumbo - El hombre quemado, que podéis escucharlo gracias al podcast de Ivoox.


Inquietante, hipnótico, delirante, chusco, bizarro... como podréis imaginar es una coña xD, en el siguiente podcast tenéis la respuesta:


Un rato de aburrimiento de Santiago Camacho, una aplicación para el móvil que transforma una conversación en música y la inspiración para preguntarle al gran Pablo Villarubia sobre el caso de Joao Prestes, y que el azar haga el resto.

En el último programa de Milenio3 también salió el tema a raíz de la sección uno de los nuestros, que entrevista a algunos de los colaboradores de la nave del misterio, en esta ocasión a Pablo, podéis escucharlo en el siguiente enlace (alrededor del minuto 18 empieza la entrevista y en el 24 hablan del tema):

http://www.ivoox.com/uno-nuestros-pablo-villarrubia-13-10-2013-audios-mp3_rf_2444051_1.html

Sin más, os dejo la canción en youtube:

Un saludo!

PD:

Por cierto, si queréis la aplicación podéis conseguirla para Android y para Iphone

Series que molan: Battlestar Galactica

Navegando me he encontrado con Katee Sackhoff y revisando las series me he dado cuenta que Battlestar Galactica no estaba entre ellas, y una de las mejores series de sci-fi, (con el permiso de Stargate) tiene que estar por aquí.

La última cena de Da Vinci Reimagina

Primero algo de antecedentes, la serie sobre la que voy a hablar es un remake de una anterior de nada menos que 1978 creada por Glen A. Larson, más que nada es todo un universo de ciencia-ficción, porque también hay libros, juegos, películas, etc.

Madre mía que viejo

En 2003 Ronald D. Moore y David Eick crean una mini-serie de 2 capítulos de 3 horas, que cosecha bastante éxito y será la responsable del resurgir de la franquicia, con la serie Battlestar Galactica 2004 y un spin-off de ésta en 2010 como precuela denominado Caprica, explicando de donde vienen los cylons y demás, esta última no tuvo tanto éxito y solo hay una temporada aunque es bastante interesante si te engancha este universo.

La muchacha es Alessandra Torresani

Pero la serie que nos reúne aquí hoy es la nueva Battlestar Galactica, en una región lejana de nuestra galaxia existe una civilización humana que ha conseguido expandirse por varios planetas conociéndose como las 12 colonias.
Tras años de paz después de una cruenta guerra con una raza de robots denominados cylons, estos deciden volver a atacar, gracias a la ayuda de un científico llamado Gaius Baltar (James Callis) el ataque pilla por sorpresa a las defensas y es un éxito.
La aniquilación es prácticamente total, dejando solo a unos pocos que tendrán que sobrevivir en una pequeña flota, liderada por la estrella de combate Galáctica (Battlestar Galactica), al mando de esta se encuentra el Comandante William "Bill" Adama (Edward James Olmos) y la presidenta Laura Roslin (Mary McDonnell), que pondrán rumbo a la mitológica decimotercera colonia, conocida como la tierra.

La flota humana, en primer plano Galáctica

Qué, interesante trama eh, pues sí que mola, el único problema es que en ocasiones se ponen demasiado filosóficos para mi gusto, dándole demasiada profundidad a la serie en temas de religión y tal que puede aburrir, aunque forma parte de su encanto, pero en general esta muy bien, batallas espaciales, conspiraciones políticas, amorios, giros de guión, sorpresas... bastante completita.

Adama, Seis, Gaius, Karl, Starbuck, Roslin, Apollo, Boomer, Saul

Hay una cantidad de personajes importante, además de los ya mencionados, el comandante Adama, la presidenta Roslin y el cabroncete de Gaius, también esta el hijo de Adama, Capitan Lee "Apollo" Adama (Jamie Bamber), la piloto de Raptor Sharon "Boomer" Valerii (Grace Park), la mano derecha de Adama Coronel Saul Tigh (Michael Hogan) o el teniente Karl "Helo" Agathon (Tahmoh Penikett). Cabe mencionar que tenemos a Lucy Lawless, no en un papel muy protagonista pero Xena siempre será Xena y hay que recordarla.

Amor puro

Luego tenemos 2 que se han convertido en mitos del frikismo, la teniente Starbuck (Katee Sackhoff), piloto de los cazas Viper, ha aparecido en plan estrella invitada en series como The Big Bang Theory. Otra es el cylon número 6 (Tricia Helfer) , mito por razones obvias.

Algunas curiosidades como por ejemplo el uso de la expresión ficticia frak, en lugar de fuck, para así poder maldecir todo lo que quisieran sin problemas xD. O la frase "So say we all!", podría verse algo así como un amen, la serie tiene un fuerte componente religioso y en momentos épicos de los discursos se suele decir eso al acabar en plan motivación.

So say we all!

Y esto es todo, hay 4 temporadas de alrededor de 20 capítulos de 40 minutos, también puedes encontrar webisodes y hasta películas, Razor narrando hechos que tienen lugar al principio de la segunda temporada, Blood & Chrome, como un precuela mostrando la primera guerra cylon, o The Plan, así que tienes material para rato, serie imprescindible para cualquier amante de la ciencia-ficción!

Un saludo.

Series que molan: House of Cards

Pues últimamente me ha dado con las series de corte político, pero es que estando tan bien llevadas ¡Se disfrutan de lo lindo!

House of Cards, adaptación de una serie homónima de la BBC, fue estrenada por el portal Netflix a primeros de año, y cosechó un éxito bastante importante, varias nominaciones a los Emmy, incluso ganando uno, el de mejor director en una serie de drama conseguido por David Fincher, superando a otras como Breaking Bad, Boardwalk Empire o Homeland.

David Fincher

La serie trata sobre los tejemanejes en la política de Washington, liderados por el congresista demócrata Francis Underwood, (Kevin Spacey), Jefe de Disciplina de la Mayoría en la Cámara de Representantes. Frank moverá los hilos como si de una partida de cartas se tratara, en la que ademas de jugar, actúa como banca. La verdad es que no me termina de gustar del todo Kevin, lo recuerdo de American Beauty y no se porque me da un rollo raro, aunque sí hay que reconocer que hace un buen papel.

La recordada escena de los pétalos

Su mano derecha es Doug Stamper (Michael Kelly), su jefe de personal, que pudimos ver en Person of Interest, actuará como el que camina alrededor de la mesa para ver las cartas de los demás jugadores, pasando información y encargándose de algún que otro trabajo sucio.

Kelly en Person of Interest

Peter Russo (Corey Stoll), otro congresista demócrata con una vida no demasiado buena ni moral como para que se haga pública, y AJA, aquí tenemos al jugador apuntado con una pistola bajo la mesa para que suba, apueste o pase exactamente cuando le convenga al señor Spacey. Comentar que también tuvo una nominación a los Emmy como mejor actor de reparto en drama este último año, y que unas declaraciones que hizo a raíz de la poca cosecha de Emmys de la serie tuvieron bastante polémica.

Las declaraciones

Otro de las partes que molan es el toque The Newsroom, representando en Zoe Barnes (Kate Mara), joven redactora que trabaja en el periódico The Washington Herald, que será la que ayude a Kevin a jugar las cartas desde el asiento de la prensa.

No va a ser todo bueno, hay una parte que no me da tanta diversión, y es la de la esposa, Claire Underwood (Robin Wright), en el piloto creía que iba a tener un enfoque más secundario pero tiene demasiado espacio, el rollo de buena tía que quiere hacer algo grande y para hacerlo tiene que hacer malas cosas y se ve tentada y eso le remuerde la conciencia... me aburre xD.

La serie cuenta con algunos elementos ademas de los tradicionales que me han llamado la atención, uno de ellos el intento de adaptarse a los nuevos medios, no solo por su emisión online, sino por el uso de los denominados "guasaps" para el común de los mortales, o mensajes de texto cortos a través de Internet, que se ven reflejados en pantalla como bocadillos azules.

Otro elemento es el uso de comentarios mirando directamente a cámara por parte de Kevin (la ruptura de la cuarta pared), como si los espectadores estuviéramos en su mente y en lugar de simplemente escucharlo en off (en plan Dexter), nos lo contara directamente.

La cuarta pared

Y se me olvidaba, el product placement marca de Apple, últimamente lo estoy viendo en cada serie, es infernal, la puñetera manzanita en todos lados xD.

Actualmente se ha emitido una temporada de 13 capítulos de 50 minutos, y hay confirmación para una segunda temporada, así que aún quedan muchas cartas por repartir, no te olvides de coger una!

Un saludo!!

Series que molan: The Newsroom

Por algún extraño motivo que no alcanzo a comprender me he puesto a ver esta serie, no sabía que era de la HBO, no sabía que trataba de periodistas (aunque por el título algo se olía), no sabía que Jeff Daniels estaba en el cast, ni siquiera Olivia Munn, pero aún así decidí ponerla a bajar a ver que me encontraba, y me alegro de haberlo hecho porque ha sido una experiencia distinta y muy interesante.

La serie es un drama con toques de política, lo que da bastante juego, aunque puede que algunas partes te cansen si no te apasiona la política, y más aun hablando de la americana, pero aun así se tocan elementos bastante universales, que aquí en España también están en constante debate, dándonos cuenta que prácticamente de lo que se habla cada noche en las típicas tertulias políticas esta en todas partes.

De izq a dch - Neil, Sloan, Don, Charlie, Jim, Will, Mac y Maggie

Pero lo que la hace grande no es tanto como trata ciertos temas, que sí que molan, sino sus personajes, y ver como funciona día a día por dentro una redacción de noticias, concretamente la de de la ficticia cadena ACN (Atlantis Cable News).
Dicha cadena esta liderada por su presentador estrella, Will McAvoy (interpretado genialmente por Jeff Daniels, tan bien que le hizo merecedor de un Emmy a mejor actor principal), tras años de parsimonia presentando unas noticias políticamente correctas sin querer molestar a nadie, estalla durante una conferencia criticando prácticamente todo lo relativo a USA, provocando graves problemas de imagen y audiencia y que se replantee intentar realmente "do the news", total, de mojados al río.

Jeff en serio, no a lo 2 tontos muy tontos

Ese soplo de aire fresco esta representado por Mackenzie McHale (Emily Mortimer), antigua pareja de Will que se hará cargo de la producción ejecutiva del programa, curtida en mil y una guerras a lo largo del mundo, junto a su colega James Harper ( John Gallagher), quien a su vez tendrá sus más y menos con Margaret Jordan (Allison Pill, ¿te suena de Scoot Pilgrim vs the World?), productora asociada que tendrá que hacerse un hueco entre tanta experiencia.

3 productores en apuros

También tenemos a Don Keefer (Thomas Sadoski), antiguo productor ejecutivo de Will que sale huyendo tras el duro golpe de audiencias y popularidad que supone la rajada de Will, Neal Sampat (Dev Patel), el geek de la familia, que se encarga de todo lo relacionado con Internet y el jefe de la división Charlie Skinner (Sam Waterston), antiguo militar.

Una de tantas discusiones

Y por supuesto la enorme Olivia Munn como Sloan Sabbith, economista que trabaja en la cadena. La recuerdo de su trabajo en la inolvidable Chuck como agente de la CIA. Olivia aparte de lo obvio tiene su lado freak, como demuestra la fotografía de abajo (ha hecho algún que otro cosplay) o su participación en ese impresionante y perturbador vídeo que puse hace algún tiempo por aquí, Ghost Tits.

Sep, es ella, y sep, es un cosplay de slave Leia

Aparte de estos hay otros recurrentes, como la CEO de la cadena padre de ACN, AWM (Atlantis World Media), Leona Lansing (Jane Fonda), o su hijo Reese Lansing (Chris Messina), presidente de AWM, la verdad es que el elenco es bastante amplio, pero todos tienen algo que aportar cuando entran en escena, mola como te adaptas a los personajes, bien construidos, y con un sentido del humor bastante peculiar, sobretodo por Will.

Will haciendo de las suyas

Su creador es Aaron Sorkin, sus trabajos incluyen ser creador de otro drama político como The West Wing o guionista de la famosa película The Social Network. Revisando su biografía es cabe mencionar que es conocido por hacer que sus personajes interpreten largos monólogos y rápidas conversaciones, lo que en The Newsroom esta más que presente, y por lo que a mi respecta, me alegro que así sea, porque nos da algunos de los mejores momentos de la serie.

Actualmente hay 2 temporadas de 10 y 9 capítulos de aproximadamente 1 hora, y confirmada una tercera temporada, con lo hay material para disfrutar.

Y para acabar os dejo una musiquilla que suena en la serie que me ha molao, melosilla pero pega bien en el momento que suena.

Un saludo!

Webs que molan - CollegeHumor

Iba a poner directamente el vídeo pero es que esta gente se sale, estarían al nivel de screenjunkies  y sus honest trailers aunque en su propio terreno.

No se si recordáis el vídeo de un rpg de Homeland que puse por aquí hace algún tiempo, pues bien era de ellos, y seguramente habréis visto alguno más, como el de Lost o el de Game of Thrones, pero es que con esto último que han sacao lo han petao...

Breaking Dead...

Ahí os lo dejo, brutal, la mezcla de Breaking Bad con The Walking Dead, joder si es que hasta me lo vería si fuera real, desgraciadamente solo es un mash up que se han currao esta gente, pero que queda genial.

Y na más, si queréis ver cosas del estilo, id a su web!

-->> http://www.collegehumor.com/

Huell waits

Dramatización de una escena de la quinta temporada de Breaking Bad, no contiene spoilers, pero no lo pillarás si no la has visto, lo que es un pecado, así que ya estas tardando!



Un saludo.

Vines - Videos cortos

Brutal esta compilación de Vines, que no son más que videos cortos de menos de 6 segundos de lo que sea, el nombre viene de la aplicación Vine, que es la que ha empezado a poner de moda esto, si quereis probarla, esta tanto para iOS y como para Android.



Web Oficial : http://www.vine.co/

Libros que molan: Historia del tiempo

[Actualizado: Si eres perro para leertelo entero, consulta el resumen que hice, Historia del tiempo: El JResumen]

En esta ocasión vamos a ponernos intelectuales, no va a ser todo entretenimiento, aunque con este libro, a la par que aprendes también te diviertes!

Como quizás podréis imaginar es un libro de física teórica, y diréis, "vengaaa, me voy a leer yo eso, tira pa' yaa", tranquilos, es un libro de divulgación científica por lo que no os encontraréis ecuaciones chungas ni matemáticas complicadas (aunque en el fondo son la base del libro, el autor intenta omitirlo prácticamente siempre, excepto para la famosa E=mc^2 de Einstein).

Y ¿Por qué os recomiendo este libro? Porque creo que a cualquier persona le puede interesar los orígenes del universo, que esta pasando con él, o cuales son las teorías de su futuro, más que nada porque estas son las preguntas casi metafísicas que en el fondo todos nos preguntamos, ¿De dónde venimos?, ¿Hacia dónde vamos?, y mediante la comprensión del universo podemos acercarnos a entenderlas.

[Después de este párrafo propio de Iker Jimenez, os comento algo más del libro.]

Sobre su autor, es el famoso físico teórico Stephen Hawking, sí, ese que va en una silla de ruedas to' futurista que salió en Los Simpsons, quizás algunos no lo sepan pero no nació asi, la esclerosis lateral amiotrófica le llego cuando estaba trabajando en su doctorado en Cambridge, aunque esta enfermedad no le ha impedido convertirse en unas de las mentes más brillantes de nuestra época, ocupando casí durante 30 años la cátedra lucasiana de matemáticas en Cambridge, que anteriormente han ocupado gente como Isaac Newton o Paul Dirac, poquilla cosa.

"Le dan dos años de vida en 1963 - Revoluciona la física la siguiente mitad de siglo"

El libro fue publicado por primera vez en 1988 y en su momento estuvo en la lista de best-sellers del Sunday Times de Londres por 237 semanas, más que cualquier otro libro, con lo que podéis haceros una idea de cuanto lo petó.

Hawking pasa en el libro desde las teorías de Aristóteles hasta la mecánica cuántica pasando por la física newtoniana y la relatividad de Einstein, dando una visión bastante completa con referencias constantes y algunas curiosidades, aportando también su visión cambiante en algunas de las teorías de las que fue firme defensor, como de la que el universo se inició en un Big Bang.

Pos eso, si os interesa este tema no dejéis pasar la oportunidad de darle una lectura porque merece la pena, además... ¡es gratis!, os lo dejo en epub en el siguiente enlace.

Historia del tiempo: Del Big Bang a los agujeros negros

Na más, un saludo!

Juegos que molan: Grand Theft Auto: Vice City

Recientemente viendo la Summer Games Done Quick que acaba de terminar por cierto, consiguiendo recaudar casi medio millón de dolares, ahí es na..., uno de los juegos que se incluyó fue el Grand Theft Auto: Vice City, y era tal la cantidad de recuerdos y buenos momentos que se me vinieron a la mente, que no podía hacer otra cosa que dedicarle una entrada a este clásico.

Creo que ya lo he comentado por aquí, pero este juego cayó en mis manos junto a otros 2 grandes a los que también guardo especial cariño, Call of Duty y Max Payne 2, probablemente de los mejores juegos de la historia, cada uno en su sitio, pero este Vice City tenía algo especial, probablemente porque fue el primero de la saga que probé, y esa libertad para ir y hacer lo que quisieras me encantó, eso de coger una Angel o una Freeway con el traje elegante e ir conduciendo por la noche en una de las avenidas, buah.

El amo

El juego en sí no traía demasiadas novedades respecto a su predecesor, pero claro, yo no sabía ni que existía GTA3, osea que para mi era todo nuevo, por lo que era sorpresa y disfrute cada segundo. Recuerdo el inicio del juego, tras la intro, te dejan en un callejón, con un admiral al lado, para que conduzcas hasta tu piso franco para descansar, y buf, si es que era la polla, conduciendo con libertad, tirando por donde querías, flipante. Mi inglés por aquellos tiempos era prácticamente nulo, pero el "Go get some sleep" lo tengo grabado a fuego.

Empieza el juego!

La banda sonora es brutal, temas ochenteros que te meten aún más en la ambientación del juego, que en mi opinión es la mejor de la saga, esa sensación de ser un capo e ir creciendo con el transfondo de Miami, rollo Scarface, inigualable.

Recuerdo cuando consigues hacerte con la mansión en la isla central, y ver después a los grupillos de subalternos vigilando la zona, es que te hacía verdaderamente ser el amo. La compra de negocios e ir recogiendo el dinerillo también era grande, la sensación de ir progresando estaba muy bien.

Con respecto al mapa, no era tan grande como ahora los suelen hacer, pero era genial, esas 2 islas, cada zona tenía su propio estilo, y repito, la ambientación es lo que le daba una vida especial.

Por supuesto también tenía sus puntos mierda, que no pudieras nadar era uno de ellos, hacía que las misiones con barcos fueran una tensión constante, más que por la conducción en sí, por el momento de volver a tocar tierra, había que rezar para que con el maldito salto saliera bien la cosa. La limitación de interiores en los edificios era otra, solo a algunos y muy contados, cuando encontraba alguno era una ilusión poder darte una vuelta por dentro, pero bastante simple.

El miedo en estado puro

Concluyendo, un clásico que seguramente estará en la mente de mucha gente como uno de los grandes.

Y nada más, me despido regalando a vuestros oídos el mejor tema del juego,

Un saludo!

Java - Como hacer una JVM | Parte 3

Continuamos con nuestro super tutorial para la creación de una JVM, si no habéis leído las 2 primeras partes hacedlo antes de poneros con esta!

Como hacer una JVM | Parte 1
Como hacer una JVM | Parte 2

Y seguimos donde lo dejamos, creando nuestro area de clases.

ClassArea

El ClassArea contendrá las clases estáticas de nuestra JVM, esa estructura estará implementada como un HashTable, el índice será el nombre de la clase y el dato una clase extra que crearemos llamada JClass, está clase actuará como recubridora de las de BCEL.

Además, como ya hemos mencionado, necesitamos poder leer un .class y añadirlo a nuestra área de clases.

Código ClassArea.java

public class ClassArea {
 private Hashtable<String, JClass> classes;

 
 public ClassArea() {
  classes = new Hashtable<String, JClass>();
 }

 public boolean addClass(JClass jClass) {
  if (jClass == null)
   return false;

  classes.put(jClass.jClassInfo.getClassName(), jClass);
  return true;
 }

 /**
  * Carga una clase del hashtable o desde directorio si se encuentra, en otro
  * caso error, ademas la anyade al classpath
  * 
  * @param name
  *            clase a cargar
  * @return
  */
 public JClass loadClass(String name) {
  JClass jClass = classes.get(name);
  if (jClass != null)
   return jClass;
  try {
   jClass = new JClass(Repository.lookupClass(name));
   addClass(jClass);
  } catch (ClassNotFoundException e) {
   e.printStackTrace();
   return jClass;
  }
  return jClass;
 }
}

Tenemos nuestro HashTable con nombre-clase, y además nuestro método para cargar clases, que usa la librería BCEL, abstrayéndonos completamente de tareas de parseo y demás, el método static lookupClass() de la clase Repository toma el nombre de una clase y devuelve el JavaClass que mencionamos en la primera parte, este lo usamos para crear nuestro propio JClass.

Código JClass.java

public class JClass {

 JavaClass jClassInfo;
 ClassGen jClassGen;
 private JField[] jFields;

 public JClass(JavaClass jClass) {
  jClassInfo = jClass;
  jClassGen = new ClassGen(jClass);
  jFields = new JField[jClass.getFields().length];
  for (int i = 0; i < jFields.length; i++) {
   jFields[i] = new JField(jClass.getFields()[i]);
  }
 }
 
 public JMethod getMainMethod() {
  return getMethod("main",null);
 }
 
 /**
  * Busca un metodo basandose en su nombre y/o signatura
  * 
  * @param methodName
  *            nombre del metodo
  * @param signature
  *            signatura del metodo o null si no se requiere
  * @return instancia del metodo encapsulado en JMethod
  */
 public JMethod getMethod(String methodName, String signature) {
  Method searchedMethod = null;
  for (Method m : jClassInfo.getMethods())
   if (m.getName().equals(methodName)) {
    if (signature != null) {
     if (m.getSignature().equals(signature)) {
      searchedMethod = m;
      break;
     }
    } else {
     searchedMethod = m;
     break;
    }
   }
  return searchedMethod != null ? new JMethod(searchedMethod, jClassGen)
    : null;
 }
  .
  .
  .
}

Podéis ver lo que sería esta clase, las referencias a las clases de BCEL y el constructor iniciando los fields. Además notar que para la creación del ClassGen es necesario usar el JavaClass.
Declaramos un método por defecto para obtener el método principal (main), que posteriormente usaremos en nuestro programa de ejecución.
Pero es importante resaltar la obtención de métodos de una clase, la búsqueda debe ser no solo por nombre, sino por signatura, recordad que java permite sobrecarga de métodos, es decir, métodos con el mismo nombre pero con distintos parámetros/valor de retorno, usando la signatura conseguimos diferenciarlos correctamente, (más sobre sobrecarga).

Código JField .java

public class JField {
 public Field fieldInfo;
 private JValue value;

 public JField(Field field) {
  fieldInfo = field;
  ConstantValue val = field.getConstantValue();
  ConstantPool cp;
  int index;
  Constant c = null;
  if (val != null) {
   cp = val.getConstantPool();
   index = val.getConstantValueIndex();
   c = cp.getConstant(index);
  }
  switch (field.getType().getType()) {
  case Constants.T_INT:
   if (val != null) {
    ConstantInteger cl = (ConstantInteger) c;
    value = new JInteger(cl.getBytes());
   } else
    value = new JInteger();
   break;
  }
 }
  .
  .
  .
}

También mostramos la clase JField, que representa una propiedad de una clase, recubriendo al Field de BCEL, y conteniendo además el valor propio del campo como un JValue, notar en su creación el uso de la ConstantPool (esta en toas partes la jodia), para permitir la creación del field con un valor por defecto, relativo a propiedades inicializadas previa creación de objeto. Se muestra solo para int pero su obtención para el resto de variables sería similar.

StackFrame

Como dijimos los frames están formados por el contador de programa, el método concreto que se esta ejecutando, y un puntero al frame padre, de nuevo creamos una clase recubridora para los métodos de BCEL, JMethod. Ademas necesitamos métodos para acceder a las instrucciones e información dentro de cada frame.

Código StackFrame.java

public class StackFrame {

 Stack<JValue> operands;
 JValue[] locals;
 private int pc;
 private JMethod method;
 private StackFrame cf;
 public byte error;

 // added
 JClass clase;

 public StackFrame(StackFrame cf, JMethod meth, JClass clase) {
  this(cf, meth, clase, null);
 }
 
 public StackFrame(StackFrame cf, JMethod meth, JClass clase, JValue thisRef) {
  int maxLocals=meth.getMaxLocals();
  if (thisRef != null) {
   locals = new JValue[maxLocals];
   if(maxLocals>0)locals[0] = thisRef;
  } else
   locals = new JValue[maxLocals];
  this.cf = cf;
  operands = new Stack<JValue>();
  pc = 0;
  error=0;
  method = meth;

  this.clase = clase;
 }

 public InstructionHandle nextInstruction() {
  return method.get(pc);
 }
  .
  .
  .
}

Arriba vemos un esquema de nuestro StackFrame, habría más métodos que podemos añadir para facilitar operaciones pero esos son los básicos. Añadimos la clase del método que se esta ejecutando para facilitar obtener información a la hora de ejecución, además notar los dos métodos constructores.
Como dije en la segunda parte de este tutorial, cuando se llama a un método de un objeto, el frame guarda en la primera posición de variables locales una referencia a ese objeto, esto es controlado en nuestra implementación comprobando si thisRef es null, y actuando en consecuencia.

Código JMethod.java

public class JMethod {

 Method methodInfo;
 MethodGen methodGen;

 public JMethod(Method method, ClassGen classGen) {
  methodInfo = method;
  methodGen = new MethodGen(method, classGen.getClassName(),
    classGen.getConstantPool());
 }
 
 public short[] getCode() {
  byte[] code = methodInfo.getCode().getCode();
  short[] codePlus = new short[code.length];
  // convert -opcodes to +opcodes
  for (int i = 0; i < code.length; i++) {
   codePlus[i] = (short) (code[i] < 0 ? code[i] + 256 : code[i]);
  }
  return codePlus;
 }
 
  .
  .
  .
}

De nuevo la clase recubridora usa la librería BCEL, destacar el método getCode() que obtiene el código del método a través de BCEL, y como mencioné lo transforma a valores positivos.

Heap

Nuestro Heap será bastante limitado y sencillo, simplemente será un array de JValue, JValue será el tipo de dato base que nuestra JVM usará, cada tipo de dato concreto deberá heredar de este JValue, por ejemplo JInteger. Además necesitamos un puntero a la siguiente posición libre de memoria.

Código JValue.java

public abstract class JValue{
 public Type type;
}

El Type es una clase de BCEL, que representa a un tipo de la JVM.

JObject será nuestra representación de objeto y como dije será un JValue.

Código JObject.java

public class JObject extends JValue {
 public int heapPtr;
 public JClass jClass;
 // campos de la clase representado para objetos
 public JField[] jFields;

 //creacion a null
 public JObject() {
  jClass=null;
  jFields=null;
 }

 /**
  * Crea un objeto con posicion heapPtr de tipo jClass. Se reserva espacio
  * para sus fields en base a los fields de jClass
  * 
  * @param heapPtr
  *            posicion en el heap
  * @param jClass
  *            clase instanciada
  */
 public JObject(int heapPtr, JClass jClass) {
  int count = jClass.GetObjectFieldCount();
  this.heapPtr = heapPtr;
  type = Type.OBJECT;
  this.jClass = jClass;
  if (jClass != null) {
   jFields = new JField[count];
   for (int i = 0; i < jFields.length; i++) {
    jFields[i] = new JField(jClass.getFields()[i]);
   }
  }
 }

 public void setFieldValue(int i, JValue val) {
  jFields[i].setValue(val);
 }

 public void setFieldValue(String name, JValue val) {
  for (int i = 0; i < jFields.length; i++) {
   if (jFields[i].getName().equals(name))
    jFields[i].setValue(val);
  }
 }

 public JField getField(int i) {
  return jFields[i];
 }

 public JField getField(String name) {
  for (int i = 0; i < jFields.length; i++) {
   if (jFields[i].getName().equals(name))
    return jFields[i];
  }
  return null;
 }
}

En la creación del objeto establecemos su tipo y creamos sus fields, en base a los que nos ofrece su clase, además añadimos una serie de métodos de utilidad para trabajar con sus propiedades.

Código Heap.java

public class Heap {

 private int nextObjectID;
 private JValue[] heap;

 public Heap(int size) {
  nextObjectID = 0;
  heap = new JValue[size];
 }
 
 /**
  * Crea un objeto de tipo mainClass y lo guarda en el heap
  * 
  * @param mainClass
  *            tipo de objeto a crear
  * @return la referencia al objeto
  */
 public JObject createObject(JClass mainClass) {
  JObject object = new JObject(nextObjectID++, mainClass);
  heap[object.heapPtr] = object;
  return object;
 }
 
 
 /**
  * Crea un objeto de tipo String y lo guarda en el heap
  * 
  * @param strValue
  *            valor del JString a crear
  * @param classes
  *            ClassArea a usar
  * @return
  */
 public JObject createStringObject(String strValue, ClassArea classes) {
  JClass stringClass = classes.loadClass("java.lang.String");

  JObject object = (JObject) createObject(stringClass);

  JArray arrayString = new JArray(nextObjectID, strValue.length(),
    Type.CHAR);
  arrayString.setStr(strValue);
  object.setFieldValue(0, arrayString);
  object.setFieldValue("count", new JInteger(arrayString.nElems));

  return object;
 }
  .
  .
  .
}

He dejado fuera la creación de arrays por simplificar algo e ir directo a los objetos que es más interesante. El constructor no tiene mucho misterio y la creación de objetos en Heap tampoco, gracias al uso del constructor de JObject, tras crearlo se añade al heap y se devuelve la referencia a la JVM para que lo añada en la pila.

Tenemos un método especial de creación de objetos String debido a la instrucción LDC, que permite la creación directa de un String y su carga en la pila, los String los hemos codificado como un JArray, (cada array se toma como otro objeto, internamente tiene un array de JValue para permitir arrays de cualquier tipo soportado por nuestra JVM), y tras la creación modificamos 2 de sus fields, el que guarda el propio String (en nuestro caso el JArray), y el que guarda su tamaño llamado count, existen otros, pero estos dos son los básicos para que nuestros objetos String puedan ser utilizados.

Ejecución

Todo esto está muy bonito pero... ¿Cómo cojones lo pongo a funcionar?, tiene algo de miga aunque no demasiado (gracias a nuestro desarrollo POO!), así que tenemos que crearnos otra clase, por ejemplo Exec, que será la que usará la JVM para ponerla a trabajar.

Código Exec.java

public class Exec {

 public static void main(String[] args) {
  execute(args[0], args[1]);
 }
 
 private static void execute(String strClass, String size) {

  // creamos heap
  Heap heap = new Heap(Integer.parseInt(size));
  // creamos area de clases
  ClassArea ca = new ClassArea();
  // leemos clase y buscamos metodo principal
  JClass mainClass = ca.loadClass(strClass);
  JMethod mainMethod = mainClass.getMainMethod();
  // creamos frame principal
  StackFrame mainFrame = new StackFrame(null, mainMethod, mainClass);

  // creamos jvm
  JVM jvm = new JVM(mainFrame, heap, ca);

  // ejecucion
  jvm.run();
 }
}

En este programa principal se toman dos argumentos, el nombre de la clase y el tamaño del heap. Cuando tenemos creadas nuestras 3 estructuras se las pasamos a la JVM y a ejecutar, (recordar que no veremos nada porque no hemos puesto ningún tipo de salida por pantalla), además si cogéis cualquier .class probablemente falle porque hay cantidad de instrucciones que no están implementadas.

El método que se ejecutará será el método main, que se obtiene mediante el método getMainMethod().

Notar que el nombre de una clase no es solo su nombre, sino que incluye el paquete en el que esta, por ejemplo si cogéis una clase llamada A.java que esta en com.prueba.tests, su nombre en realidad es com.prueba.tests.A.

Conclusión

Bueno, hasta aquí hemos llegado, hay algunas cosas que han quedado en el aire (excepciones, propiedades static, recolector de basura, threads) pero para un tema tan denso como es la máquina virtual de java creo que se ha presentado información bastante útil para cualquiera que quiera empezar a indagar en este mundillo, nada más.

Un saludo!

Ghost Tits - Olivia Munn

La nueva época del terror esta aquí, tras Paranormal Activity o Insidious, llega... Ghost Tits!



Sin palabras... ajajja

E3 - This is how Sony trolls Microsoft

Shu Yoshida y Adam Voyes explican como se comparten los juegos en la nueva PS4.



Sin comentarios xD

Java - Como hacer una JVM | Parte 2

Continuamos este tutorial para realizar nuestra home made virtual machine, la primera parte la podéis encontrar en este enlace.

Habíamos preparado la mente para saber como empezar a programar, así que vamos allá, y empezaremos pasando a código lo que ya sabemos, como está estructurada nuestra JVM.

JVM.java

Ya dijimos que la JVM esta formada por 3 partes, la zona de clases, el heap y los frames, además sabemos que tendrá que ir leyendo instrucciones de los archivos .class y ejecutarlas en función de cual sea dicha instrucción, bien, pues pondremos eso en código. He decidido ir descomponiéndolo porque meterlo todo del tirón puede ser demasiao lioso.

Primero definimos las 3 estructuras tal y como ya sabemos, son clases que deberemos crear más adelante y establecemos un constructor para la JVM, además hacemos que implemente Runnable y por tanto el método run().
Dentro de este método run() podríamos tener distintos tipos de ejecución como se mencionó en la primera parte pero para no complicar el tema tomaremos solo la ejecución directa con OPCODE.

Código Base

public class JVM implements Runnable {

 private StackFrame topFrame;
 private Heap heap;
 private ClassArea classes;
 
 public JVM(StackFrame topFrame, Heap heap, ClassArea classes) {
  this.topFrame = topFrame;
  this.heap = heap;
  this.classes = classes;
 }
 
 public void run() {
  runOPCODE();
 }
}

Para esta ejecución tenemos un método runOPCODE(), que declara 2 variables, un array de short y un short, cada uno representará el código completo del método y el código de operación actual.

Y podréis preguntaros ¿Por qué son short si te has hartado de decir que la información en los .class esta en forma de bytes? Primero, con 8 bits tenemos 256 combinaciones, suficientes para los 212 opcodes, pero internamente los byte en Java están en complemento a 2, osea que van desde -2^7 a 2^7-1, así que bcel guarda la codificación de los opcodes superior a 2^7-1 como negativos, pero a la hora de la verdad son positivos, por lo que hacemos esa transformación de byte a short para permitir valores superior a 2^7-1, en la clase JMethod lo veremos.

Después de eso tenemos el bucle de ejecución, que debe seguir funcionando mientras tengamos algo que ejecutar (el frame actual no sea null), y no tengamos ningún error. Hacemos una distinción a la hora de ejecutar por si el método es nativo o no, si lo es el control pasa al método especial ejecutarNative(), sino, obtenemos el código del método, la instrucción a ejecutar y usamos el método ejecutarOPCODE(), todo esto haciendo uso de los métodos de StackFrame y de la clase JMethod, que todavía no hemos visto, pero que es fácil intuir que hacen.

Código runOPCODE()

private void runOPCODE() {
  short[] code;
  short opcode;
  
  while (topFrame != null && topFrame.error == 0) {
   if (topFrame.getMethod().isNative())
    ejecutarNative();
   else {
    // ejecucion acceso directo bytecode
    code = topFrame.getMethod().getCode();
    opcode = code[topFrame.getPC()];
    ejecutarOPCODE(code, opcode);
   }
  }
 }

Para el método de ejecución usamos una estructura switch-case, en función de qué tipo de opcode tengamos se realizará una ejecución u otra, he puesto solo algunas instrucciones aunque como digo son muchas más, pero para haceros una idea esta bien. Para saber como implementar cada una nada mejor que primero revisar la lista básica:

http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings

Y después revisar la ayuda de Jasmin (un ensamblador para la JVM algo más simple), por ejemplo el siguiente enlace es para putfield:

http://www.vmth.ucdavis.edu/incoming/Jasmin/ref-putfield.html

Código ejecutarOPCODE()

private void ejecutarOPCODE(short[] code, short opcode) {
  short pos, parteA, parteB, cons, type;
  // segun opcode exec instruccion
  switch (opcode) {
  case Constants.NOP:
   ejecutarNOP();
   break;
  // /////////////// Stack Operations ////////////////
  // Instructions that push a constant onto the stack
  case Constants.ICONST_M1:
  case Constants.ICONST_0:
  case Constants.ICONST_1:
  case Constants.ICONST_2:
  case Constants.ICONST_3:
  case Constants.ICONST_4:
  case Constants.ICONST_5:
   ejecutarICONST(Integer.valueOf(opcode - Constants.ICONST_0));
   break;
  // Instructions that load a local variable onto the stack
  case Constants.ILOAD:
   pos = code[topFrame.getPC() + 1];
   ejecutarILOAD((byte) pos);
   topFrame.incPC();// saltar index
   break;
  // Instructions that load a local variable onto the stack
  case Constants.ILOAD:
   pos = code[topFrame.getPC() + 1];
   ejecutarILOAD((byte) pos);
   topFrame.incPC();// saltar index
   break;
  case Constants.ISTORE:
   pos = code[topFrame.getPC() + 1];
   ejecutarISTORE(pos);
   topFrame.incPC();// saltar index
   break;
  // Integer arithmetic
  case Constants.IADD:
   ejecutarIADD();
   break;
  // ///////////// Objects and Arrays ////////////
  // Instructions that deal with objects
  case Constants.NEW:
   parteA = code[topFrame.getPC() + 1];
   parteB = code[topFrame.getPC() + 2];
   ejecutarNEW(getIndex(parteA, parteB));
   break;
  case Constants.GETFIELD:
   parteA = code[topFrame.getPC() + 1];
   parteB = code[topFrame.getPC() + 2];
   ejecutarGETFIELD(getIndex(parteA, parteB), lastDec);
   break;
  // ////////////Control Flow /////////////////////
  // Conditional branch instructions
  case Constants.IFEQ:
   parteA = code[topFrame.getPC() + 1];
   parteB = code[topFrame.getPC() + 2];
   ejecutarIFEQ(getIndex(parteA, parteB), lastDec);
   break;
  // ////////////////////// Method Invocation and Return ////////
  // Method return instructions
  case Constants.RETURN:
   ejecutarRETURN();
   break;
  case Constants.IRETURN:
   ejecutarIRETURN();
   break;
  // Method invocation instructions
  case Constants.INVOKESPECIAL:
   ejecutarINVOKEBC(null, code);
   break;
  case Constants.INVOKESTATIC:
   ejecutarINVOKEBC(Constants.INVOKESTATIC, code);
   break;
  case Constants.INVOKEVIRTUAL:
   ejecutarINVOKEBC(null, code);
   break;
  default:
   error(topFrame, "opcode no reconocido");
   break;
  }
 }

Mencionar el método getIndex(), cada opcode de la JVM ocupa un byte, y si usa parámetros van codificados a continuación usando otros byte, el tema esta que los índices a la ConstantPool van codificados como 16 bits, pero separados en 2 bytes (uno con los 8 bits más significados y otro con los 8 menos), asi que para formar el índice completo hay que coger cada byte por separado y generar el short (de 16bits), para ello hacemos uso de la clase ByteBuffer (probé distintas formas ésta es la que me funcionó).

Código getIndex()

/**
  * Construye un indice de 16 bits separado en 2 bytes
  * 
  * @param subi1
  *            primera parte indice
  * @param subi2
  *            segunda parte indice
  * @return el indice completo
  */
 private int getIndex(short subi1, short subi2) {
  ByteBuffer bb = ByteBuffer.allocate(2);
  bb.order(ByteOrder.BIG_ENDIAN);
  bb.put((byte) subi1);
  bb.put((byte) subi2);
  short index = bb.getShort(0);

  return index;
 }

Para la ejecución de métodos nativos, según leí hay distintas formas de abordarlo, yo elegí la más simple, cuando detectamos el método nativo, obtenemos cual es, mirando su signatura y nombre, y usando una clase de ayuda llamada Natives hacemos su ejecución utilizando código Java, aunque podría hacerse de otras formas. Por ejemplo nuestro método print() escribe por pantalla, y para ello usa el método System.out.print().

Código ejecutarNative()

private int ejecutarNative() {
  JValue val = null;
  String sig = topFrame.getMethod().getFullNameAndSig();
  if (sig.equals(Natives.SIGS[0])) {
   val = Natives.fillInStackTrace(this);
  } else if (sig.equals(Natives.SIGS[1])) {
   val = Natives.print(this);
  } else if (sig.equals(Natives.SIGS[2])) {
   val = Natives.println(this);
  } else if (sig.equals(Natives.SIGS[3])) {
   val = Natives.getIntFromStr(this);
  }
  if (val != null) {
   topFrame.push(val);
   ejecutarXRETURN();
  } else
   ejecutarRETURN();
  return 0;
 }

Código print() en Natives.java

public static JValue print(JVM jvm) {
  JObject ostr = (JObject) jvm.topFrame.locals[0];
  JArray arraystr = (JArray) ostr.getField(0).getValue();
  StringBuffer sb = new StringBuffer();
  for (int i = 0; i < arraystr.nElems; i++) {
   sb.append(arraystr.get(i));
  }
  System.out.print(sb);
  return null;
 }

También os dejo la implementación de algunas de las instrucciones, he comentado el código para que quede más claro y más o menos creo que debería entenderse.

Código implementación algunas instrucciones

private void ejecutarNEW(int index) {
  JObject object;
  //usamos constant pool para obtener nombre de clase en base a su indice
  ConstantPool cp = topFrame.getConstantPool();
  ConstantClass cc = (ConstantClass) cp.getConstant(index,
    Constants.CONSTANT_Class);
  String className = cc.getBytes(cp);
  //cargamos clase y creamos objeto a traves de heap
  JClass jClass = classes.loadClass(className);
  object = heap.createObject(jClass);

  //añadimos objeto a la pila y saltamos parametros
  topFrame.push(object);
  topFrame.incPC(3);
 }
 
 private void ejecutarRETURN() {
  //return sin valor, simplemente volvemos al frame padre
  setTopFrame(topFrame.getCf());
 }
 
 private void ejecutarIRETURN() {
  if (topFrame.size() != 1)
   error(topFrame, "Tamaño de pila para return distinto de 1");
  JValue val = topFrame.pop();
  StackFrame previous = topFrame.getCf();
  if (previous == null) {
   error(topFrame, "No hay frame previo para return");
  } else {
   previous.push(val);
   setTopFrame(previous);
  }
 }
 
 //para este metodo usamos un truco a la hora de llamarlo,
 //las instrucciones const estan codificadas de manera consecutiva, 
 //asi obtenemos el valor correcto restando cada una a la primera
 private void ejecutarICONST(int n) {
  topFrame.push(new JInteger(n));
  topFrame.incPC();
 }
 private void ejecutarILOAD(byte pos) {
  topFrame.push(topFrame.locals[pos]);
  topFrame.incPC();
 }
 
 private void ejecutarISTORE(int pos) {
  JValue val = topFrame.operands.pop();
  topFrame.locals[pos] = val;
  topFrame.incPC();
 }
 
 private void ejecutarIADD() {
  //cada tipo tiene su clase concreta, así para sumar 
  //dos enteros usamos el metodo de clase y add a la pila
  JInteger op1 = (JInteger) topFrame.operands.pop();
  JInteger op2 = (JInteger) topFrame.operands.pop();
  topFrame.push(op1.add(op2));
  topFrame.incPC();
 }
 
 private void ejecutarIFEQ(int index) {
  //en base al valor en la pila saltamos a index o no
  JInteger val = (JInteger) topFrame.pop();
  if (val.getValue() == 0) {
   topFrame.incPC(index);
  } else {
   topFrame.incPC(3);
  }
 }

Por último la invocación de métodos, el mismo método lo usamos para los 3 tipos de invocación.

Código invocación de métodos

private void ejecutarINVOKEBC(Short stat, short[] code) {
  // get clase y method info a partir de BC
  ConstantPool cp = topFrame.getConstantPool();
  ConstantMethodref methodIndex = (ConstantMethodref) cp
    .getConstant(
      getIndex(code[topFrame.getPC() + 1],
        code[topFrame.getPC() + 2]),
      Constants.CONSTANT_Methodref);
  // get clase
  // modo largo, siguiendo cadena referencias
  // ConstantClass classIndex =(ConstantClass)
  // cp.getConstant(methodIndex.getClassIndex(),Constants.CONSTANT_Class);
  // ConstantString stringClassIndex=(ConstantString)
  // cp.getConstant(classIndex.getNameIndex(),Constants.CONSTANT_String);
  // ConstantUtf8 utf8ClassIndex=(ConstantUtf8)
  // cp.getConstant(stringClassIndex.getStringIndex(),Constants.CONSTANT_Utf8);
  // String className =utf8ClassIndex.toString();

  // USANDO ATAJO
  String className = methodIndex.getClass(cp);

  // get method
  ConstantNameAndType nameAndTypeIndex = (ConstantNameAndType) cp
    .getConstant(methodIndex.getNameAndTypeIndex());
  String methodName = nameAndTypeIndex.getName(cp);
  String signature = nameAndTypeIndex.getSignature(cp);

  JClass jClass = classes.loadClass(className);
  JMethod jMethod = jClass.getMethod(methodName, signature);

  // maximo argumentos
  int maxArgs = jMethod.getMaxArgs() + 1;

  // si es estatico disminuyo params
  if (stat != null)
   maxArgs--;
  // get pila en orden para parametros
  Stack<JValue> stack = topFrame.getParamsReverse(maxArgs);
  topFrame.clearParams(maxArgs);

  StackFrame newTopFrame;
  int desp = 0;
  if (stat != null) {
   newTopFrame = new StackFrame(topFrame, jMethod, jClass);
  } else {
   // si no es estatico, meto referencia en locals[0]
   desp = 1;
   JObject ref = (JObject) stack.pop();
   newTopFrame = new StackFrame(topFrame, jMethod, jClass, ref);
  }
  // paso parametros tras que se ha creado la estructura
  for (int j = 0; j < maxArgs - desp && !stack.empty(); j++) {
   JValue val = stack.pop();
   // si no es el primero y el anterior ocupa 2 espacios, lo desplazo
   if (j != 0
     && (newTopFrame.getLocals()[j - 1].type == Type.LONG || newTopFrame
       .getLocals()[j - 1].type == Type.DOUBLE)) {
    newTopFrame.getLocals()[j + desp + 1] = val;
   } else
    newTopFrame.getLocals()[j + desp] = val;
  }
  topFrame.incPC(3);
  setTopFrame(newTopFrame);
 }

Alaaaa, sí, todo esto para invocación de métodos, primero tenemos que obtener que método vamos a llamar, esa información esta en una constante MethodRef de la ConstantPool así que lo obtenemos usando el índice de su posición que viene codificado en los dos siguientes bytes de la instrucción. El método getConstant() de BCEL nos facilita realizar esta operación, el segundo parámetro sirve para especificar que tipo de constante queremos obtener, saltando una excepción si no es ese (útil para debug).

Tras eso ya tenemos la referencia al método pero necesitamos su clase! He dejado comentado la manera "larga", la que sigue la cadena de referencias de la ConstantPool, pero por suerte BCEL nos proporciona un método llamado getClass() para obtener directamente ese valor.

Como dije tenemos la referencia al método pero ni su nombre ni su signatura, esa información esta en una constante NameAndType, de nuevo usamos la ConstantPool y voila, ya podemos crear nuestro JClass y JMethod. Además necesitamos saber el número de parámetros del método.

El tratamiento de métodos static lo hacemos ahora, cuando no es static, una referencia al objeto que lo llama se guarda en la primera posición de variables locales, si lo es, simplemente disminuimos el valor. Otro punto que hay que notar es que el paso de parámetros se hace en orden contrario al de la pila, de ahí el uso del método auxiliar getParamsReverse(), que nos da la pila de parámetros en orden para luego meterlos en el array de variables locales.

Luego creamos el frame en función de si es static o no, y por último el paso de parámetros en sí. Básicamente va sacando elementos de nuestra pila de argumentos y los mete en el array de locales, pero hay que resaltar varias cosas. Primero si es static o no, de ahí el valor desp para no sobreescribir la referencia al objeto, y además los valores long y double, que en la JVM ocupan dos "espacios". En esta implementación ocupa 1 pues todo son JValue, pero de todos modos tenemos que hacer que ocupen dos pues las referencias en el bytecode serán a su posición real.

UFF, bueno todo eso sería para nuestra clase JVM, mucho curro y todavía solo hemos empezado porque... ¿Cómo implementamos las 3 partes que no tenemos? ¿Dónde se hace la lectura de los .class? Adelanto que de eso se ocupará nuestra clase ClassArea.

Bueno, de esa clase y del resto de nuestra JVM hablaré en la tercera parte y final (espero) de este tutorial.

Un saludo.

---

Tercera parte ya disponible!

---