Mostrando postagens com marcador JavaEE. Mostrar todas as postagens
Mostrando postagens com marcador JavaEE. Mostrar todas as postagens

24 janeiro 2014

Hackathon de Java e Raspberry Pi na CPBr14


Você que é desenvolvedor Java e vai para a Campus Party na semana que vem de 27 de Janeiro a 2 de Fevereiro de 2014, não pode perder o Hackathon de Java e RaspberryPi promovido pelo SOUJava, com apoio da Oracle, trazendo kits, premiação, e mentoring! O objetivo é aprender, praticar e inovar, e todos os participantes ainda vão ganhar uma camiseta. Um dos projetos será selecionado para apresentação no palco principal!

Presença de grandes nomes da comunidade Java brasileira como:

Para maiores informações, consulte o site do SOUJava Hackathon de Java e Raspberry Pi na Campus Party.

11 novembro 2013

Reality of Open Source Users in Mobile and Cloud Era

- "I built my Android app entirely with Open Source products, both in the app, and in the backend server running on Amazon. I'm charging US$ 1,99 for it in the Google Play Store" 
- "That's wonderful! Where is the source code of your app? Have you contributed back to these Open Source products? Will you release your product as Open Source?"

In this new era of Cloud Computing and Mobile apps, there's an increasing number of for-profit products that takes advantage of Open Source products, but barely contribute anything back to them, either by buying support, or non-expensive things such as reporting bugs, fixes, or helping documentation. Developers are building SaaS applications for Salesforce.com, or Mobile apps for Android and iOS devices, and usually charge for these. Of course, they want to make money as anyone else.

Whenever I ask someone that makes money with _their_ software built on top of Open Source, if they will ever release the source code, they usually answer: "my case is different". Well, why is your case different? Why can't I buy your app from Google Play Store, and still access the code on GitHub? Or build it on my own, customize it, etc? That's the point of Open Source, right? Wrong, in their minds.

Majority of software developers actually tend to think that Open Source is free as in free beer. And that's it. No matter how hard you try to explain otherwise, the industry will almost always see Open Source software as free software. And due to the new way to sell software, I really think that Mobile apps and Cloud SaaS/PaaS offers will, sooner or later, kill good Open Source softwares, and leave this space only for conceptual and initial implementations for Open Standards and APIs, or for general use and development platforms and languages such as Java, Ruby, etc.

Perhaps you want to read Will Cloud kill Open Source? Is the Future Open Standards? Your thoughts are welcome :-)

10 setembro 2013

Java SE 7 update 40 e o Mission Control 5.2

Java SE Downloads
Chegou uma nova atualização do Java SE 7: update 40. Esta versão inclui várias novas funcionalidades como o Java Mission Control, Deployment Rule Set, suporta para o Retina display no Mac, e suporte a Hard Float ABI no Linux ARM v7. Também inclui diversas correções de bugs. Para quem desenvolve Applets e aplicações Java Web Start, este release, fica a atenção para conhecer e enteder as mudanças.

Deployment Rule Sets

Esta funcionalidade permite um administrador de desktops a controlar o nivel de compatibilidade para clientes Java assim como níveis de segurança para a empresa. Para maiores detalhes, veja a documentação do Deployment Rule Set.

Java Mission Control

O Mission Control era até então uma ferramenta disponível para clientes Oracle, e que foi lançada há muito tempo atrás junto com o JRockit (JRMC). Mas a Oracle agora disponibilizou a ferramenta junto com a JRE HotSpot 7u40. 

Esta ferramenta permite monitorar, gerenciar, introspectar, e detectar memory leaks nas suas aplicações Java, sem ter que introduzir códigos para isso, que normalmente degradam a performance da aplicação. Hoje esta ferramenta está agora disponível no download do Oracle HotSpot JDK 7u40!

Flight Recorder

Mas a principal e mais importante característica é o Flight Recorder. Este recurso funciona através da leitura de eventos produzidos pela JVM. Mesmo ativando a geração destes eventos, a sobrecarga total  para as suas aplicações ainda fica abaixo de 2%, que considerando o tipo e o valor de informação que você recebe, é quase nada. Um exemplo de evento é a chamada de um método de uma classe Java.

Com o profile de chamadas de métodos você pode descobrir onde o aplicativo está gastando a maior parte do tempo executando seu código Java. Este é, por exemplo, útil para otimizar a aplicação onde as otimizações realmente terão impacto. Isto sem precisar introspectar seu código manualmente!

Alem disso, você tem também uma visão de otimização para alocação de objetos. Você pode ver por exemplo, a alocação em tempo real de objetos na Old Gen da memória heap. diretamente no espaço de idade, além de outras abas que oferecem diversas informações importantes sobre o processamento de informações na sua aplicação Java. Leituras de arquivos I/O, Socket I/O e muito mais.

Se você precisa de mais informações sobre o Mission Control, entre na página da ferramenta em www.oracle.com/missioncontrol.

E obrigado ao Markus Eisele por ter cedido parte deste post! :-)

08 maio 2013

What's new in Java EE 7 at JUDCon Brazil 2013

This weekend I talked about Java EE 7 at JUDCon Brazil 2013, the session "What's new in Java EE 7? From HTML5 to JMS 2.0". What a great honour to be at JBoss Users and Developers Conference to share with attendees the great work that Oracle, Red Hat, and many others are doing for this platform. Room was packed, with people standing, and so much interest to hear all the cool stuff to come, such as WebSockets, JMS, JAX-RS, JSF and even more. To add some value to this talk, and as I'm a fan of Game of Thrones, I thought that a few images would fit right at this talk :-)
            
Slides here!

22 abril 2013

What's new in Java EE 7 at JUDCon Brazil 2013

This weekend I talked about Java EE 7 at JUDCon Brazil 2013, the session "What's new in Java EE 7? From HTML5 to JMS 2.0". What a great honour to be at JBoss Users and Developers Conference to share with attendees the great work that Oracle, Red Hat, and many others are doing for this platform. Room was packed, with people standing, and so much interest to hear all the cool stuff to come, such as WebSockets, JMS, JAX-RS, JSF and even more. To add some value to this talk, and as I'm a fan of Game of Thrones, I thought that a few images would fit right at this talk :-)





Slides here!








via Java and everything https://blogs.oracle.com/brunoborges/entry/what_s_new_in_java

22 fevereiro 2013

Encontro SouJava na Oracle (JMS e Cache Distribuido)

No dia 21 de Fevereiro estreamos o novo escritório da Oracle abrindo as portas para o grupo de usuários do SouJava. Com a presença do Bruno Souza, Ricardo Ferreira, Edgar Silva, Vinicius Senger, Mauricio Leal e muitos outros, tivemos a participação ao todo de 26 pessoas.

Durante a reunião, apresentei As Novidades do JMS 2.0, parte importante do Java EE 7 e que teve votação do Public Review no dia 19/02. O SouJava votou a favor, não só pela qualidade mas também pela transparência da especificação.

A outra apresentação foi do Ricardo Ferreira, falando sobre Processamento de Dados em Memória usando Elastic Data Grid (In-Memory Computing), que demonstrou a importância do uso de cache distribuído em arquiteturas altamente escaláveis, com o Oracle Coherence.

No final, os participantes conheceram o novo escritório da Oracle e ainda foram muito bem recebidos com muita pizza. Confira as fotos do evento!

07 janeiro 2013

Reasons to why I'm reconsidering JSF

In December 2010, I wrote a blog post entitled "Top 10 reasons why I don't like JSF", and I would guess that 50% agreed with me, the other 50% did not. No surprise, it's like religion.

I always liked to research products, projects, frameworks and Java technologies in general, but specially in the Web Development area. In 2001, I started coding JSP and Servlets, just a few months after I learned how to program in Java and do OOP . Did my first web application connecting to an Oracle DB with pure JDBC. Learned from the basics, on my own and succeeded.

Later I got a new job, thanks to my experience in Web Development, but my employer was using Apache Struts. I knew about that upfront so I studied it before my interview. Got hired. Struts back then, wasn't that hard for someone already with knowledge about HTTP request/response architecture and the Servlet specification. Then came JSF 1.0. I didn't like it. Complex. Way too much. Struts was much simplier. JSF 1.1? Same thing. Small improvements only.

So I moved to something different. In 2007, I heard about Apache Wicket. Then I became an independent evangelist. I gave several talks in Brazil, for years, spreading my word about Wicket, at every conference my talk was approved. I even created a community, Wicket em Português, for Portuguese speakers. I also offered an online training for it. I was offered a job proposal just because I knew Wicket, in Rio de Janeiro in 2010.

Now, the reason I told you all this is to show you that I'm used to choose what works best for me, at a certain time. I do change my opinion over things. It's something like, readaptation. We all should readapt. Every time. Just to demonstrate: I was born in an island, Florianópolis, then I moved to São Paulo, later I moved to Rio de Janeiro. Now I'm back to São Paulo. My accent changed, thanks both because I like to talk like others to make jokes, but also to feel like a local. By the way, I'm a CouchSurfer. I enjoy traveling and being with, and like, locals.

Now let's get to the real thing: Java Server Faces 2.2. The version that is leading me to readaption.

Before start, I should point that I now work at Oracle and I advocate in favor of Java EE. I'm friend of Arun Gupta, Reza Rahman, Ed Burns and several other folks who are Java EE advocates, also some who are not Oracle employees.

When I wrote about the things I didn't like in JSF, some were technical, others were related to its ecosystem and the market. Things that change, that evolve. And they did.

1. Pure HTML
I talked to Ed Burns several times about the way we design pages in JSF, with tag libraries. At the first opportunity, years before joining Oracle, I told him: "Hey, why don't you make it look like Wicket?". Facelets came at some point between that day and later. Now, in JSF 2.2 it's possible to define a page using pure HTML, letting the browser do the preview without much hassle. Something I enjoy a lot in Wicket and other frameworks. Something I talked a lot at my presentations. So here it is, the community (represented by myself and many others), influencing change in an specification.

2. Implementations
I think that relying on whatever is running on your application server (Mojarra or MyFaces) is better. If you are considering JSF, you should choose a Java EE certificated app server and just use whatever comes within. Life will be much easier this way.

3. Creating custom components
In JSF 1.x, creating a custom component was more difficult than creating YAJWF. Now is a one-file-in-a-directory only. It's very easy to compose a custom, reusable component. This post will give you an idea.

4. Documentation
I used to complain about JSF documentation (fragmentation). Apparently, documentation got a lot better. The Java EE 6 homepage at Oracle offers hundreds of pages of documentation. Of course you can always look somewhere else for docs, but I would go to these first, as these are the "official" docs, much like when you go to SpringSource for Spring MVC documentation.

5. Tooling Support
I've been playing with NetBeans for quite a while and it is a good IDE for Web development. But if you are really into HTML5, then you will like JSF inside NetBeans. The IDE now provides a feature, from Project Easel, that integrates with your browser and provides debugging and many other features. Good for someone doing HTML5 development with JSF 2.2 and JAX-RS. By the way, there is some work going on, according to Ed Burns, on integrating JSF 2.2 and JAX-RS 2.0. So let's keep an eye on that.

6. Other new features
Some otther new features are about to come as well. Here are some tickets in JIRA that are being prioritized, like:

  • Loading Facelets through ResourceLoader
  • Ajax File Upload component
  • Cross Site Request Forgery Protection
  • Faces flows

99. Java EE advocate
I always was an advocate of the platform though never of all of its specs. And one of the reasons I took the job at Oracle as Product Manager, was because I have been working with Java EE since... ever. Not with JSF specifically I confess, not always, but I was already considering it since it turned 2.0. And facing the challenges of teaching developers to do non-Java EE development the right way, I had been thinking of adopting it fully, simply because it's easier to find skilled developers of the platform. This is a great deal for employers when their time-to-market is important.

Still... some gaps
If there's something that I still think that happens, is the compatibility between implementations. The TCK does not cover everything, because of gaps in the spec. So it's not guaranteed to say that a project running with PrimeFaces or RichFaces on top of Mojarra will run just fine if you move it to an application server running MyFaces. But this is something that can be fixed, and I'm sure it's being addressed by all parties (JSF EG, myfaces-devs and mojarra-devs).

Also, it would be nice to see more things like server-side UI programming, as it happens with Apache Wicket. Maybe even having support for different languages? It would be nice to have the server-side UI logic in Javascript, for example. :-)

Java EE 7 and the future
Non standard frameworks are good for innovation. Some may not agree, but JCP and standards are not that slow anymore. Of course they still are if you compare to stuff like Node.js, Wicket, Liftweb, Play!, Rails and other great alternatives for web development. But look at JSF 2.2 and Java EE 7. We are about to see the new version of Java EE about the same time as HTML5 comes to a final version. In old days, it could be like having Java EE supporting HTML5 in... what? 2018? Not anymore.

Also, if you want to use JSF with CDI, you should really consider an application server with at least Java EE Web Profile, like Apache TomEE. Oracle GlassFish and JBoss are another option if you are looking for open source solutions. The reason to choose a compliant Java EE app server is that they already offer (and test) these kinds of integrations (e.g. JSF with CDI).

So yes, I look forward to Java EE Platform 7.0, not only as an advocate, but specially as a developer. I'm seeing its value, its improvements, and its readaption to the market.

Openness to Change
Let's not forget, the Adopt-a-JSR program offers the community, a great opportunity to participate, speed up, and improve even more the platform and all of its specifications. So here's your chance to ... why not, fill the gaps? :-)

Cheers!

04 janeiro 2013

Issue dev'ing RESTful JSON services on NetBeans


Here is a tricky issue that you may find if you are developing RESTful services with Java EE on NetBeans and GlassFish or WebLogic. If you want to support the JSON format but need to access some implementation classes like @JsonIgnore, you need to add the JAX-RS RI, Jersey, to your project's Libraries definition. How to add the RI? You will probably do this:
  1. Open project's Properties (right click on the project)
  2. Go to Libraries
  3. Click on 'Add Library'
  4. Select 'Jersey 1.8 (JAX-RS RI)
But you won't have your service running fine. You may find these exceptions: (added here so Google can help future users)
1 - If you try to access your RESTful service to get a JSON format of it, you will get this exception:
com.sun.jersey.spi.inject.Errors$ErrorMessagesException
  at com.sun.jersey.spi.inject.Errors.processErrorMessages(Errors.java:170)
  at com.sun.jersey.spi.inject.Errors.postProcess(Errors.java:136)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:199)
2 - If you try to access your RESTful service to get an XML format, you will get this exception:
java.lang.RuntimeException: javax.naming.NameNotFoundException: Unable to resolve 'com.sun.jersey.config.CDIExtension'. Resolved 'com.sun.jersey.config'; remaining name 'CDIExtension'
  at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
  at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.(CDIComponentProviderFactory.java:92)
  at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
  at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:576)
  at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
 If you look at your server's log, (in my case, I was using WebLogic 12c) you may find this message somewhere:
WARNING:
**********
The application is using ServletContainerInitializer class com.sun.jersey.server.impl.container.servlet.JerseyServletContainerInitializer that is loaded from:file:/labs/wls1211/modules/com.sun.jersey.server_1.1.0.0_1-9.jar. This initializer overrides the one available in the system.
**********
When you added Jersey to your library, the "package" checkbox was checked by default. So the JAR ended up going into WEB-INF/lib of your project, conflicting to the already provided by the container. 
So, how to fix this issue? Follow these steps:
  1. Open project's Properties (right click on the project)
  2. Go to Libraries
  3. Uncheck the checkbox 'Package' for Jersey 1.8 (JAX-RS RI)
  4. Click on 'OK'
  5.  Clean & Build (right click on the project) ---> remember to clean and rebuild your project
  6. (re)Deploy application
Done! :_)
https://blogs.oracle.com/brunoborges/entry/issue_dev_ing_restful_json

11 dezembro 2010

Top 10 reasons why I don't like JSF

At this JavaOne Brasil, there was a great discussion about Java Web Frameworks, with folks from Caelum, GlobalCode and Oracle. Arun Gupta, Maiko Rocha, Vinicius and Yara Senger, and many others who came to participate.

The discussion went mostly around what companies and developers should do before choosing a Web Framework. Although I was willing to move the discussion to another level (eg, poiting these 10 reasons), I decided to just take it easy. And as I stated: there's no perfect Web Framework. But there's a perfect web framework for your case.

But now I think it is the right time and place to share my thoughts. Here are my top 10 reasons (mostly non-technical) on why I don't like JSF.
  1. Extra step when defining a project's architecture
    People insist on comparing JSF with other frameworks. They should stop doing that. You can compare MyFaces to RichFaces to Tapestry to Vaadin to GWT. JSF is a specification, not a final product.

    Vendors too insist on marketing JSF as a Web Framework. But they forget to mention that you will be locked-in to their implementation because of lots and lots of non-standard components. It ain't cool.

    You spend a week comparing *one* JSF implementation with other frameworks, and if you chose JSF, you then realize you have an extra step: you have to pick a vendor, an implementation, and then goes another week of POCs, tests and evaluations. And you'll be locked. It is not easy to move from one to another. Specially when you have to use those non-standard components to turn your project on something really functional.

  2. Fragmented Community
    Now, let's say you, developer, works on a project for 6 months, on top of RichFaces. Then you move to another project built on top of MyFaces. Yes, you will have to sign in to another mailing list. To another forum. Different from other products, JSF has no centralized community. If you are working with Wicket, you go to users@wicket.apache.org. If you are working with VRaptor, you go to their Forum. If you are working with JSF, you will need to sign up for at least 3 different mailing lists, sign up for 3 forums and probably, tens of blogs.

    It is not easy to ask for help on a fragmented community. If you face a problem with RichFaces, when you were used to work with ICEFaces, you might end up asking something stupid, and probability is you will be told of a different solution to the same problem.
     
  3. Fragmented Documentation
    If community is important, imagine documentation. You must have bookmarks of all JSF implementations. If you work with GWT, you need only one. If you work with SpringMVC, just go to springframework.org. Also there's the problem of non-standard components. Let's say you are working with Seam, and you have to bind some component to some RichFaces component. Where will you find a documentation about that? There's no such thing. If you are luck, you might find some blog post on Google. Odds you won't find. You will discover by yourself after hours of debugging and tracing, and in the end, you will not blog about that too. You will just move on.

  4. Component Incompatibility
    Well, there's not much to say on this. JSF 2.0 address some issues, but not all of them. Component interoperability between different components can't be easily documented because of JSF's nature. This (documentation) also happens on some non-standard frameworks, but there are others that the core architecture helps a lot the developer to just don't care about this. Wicket is one of them. Components are grained and independent. If you want to interoperate different components, you simply share a Model or deal with events.

  5. Caveats on some scenarios because of different implementations
    This one I heard from a JSF developer. He said RichFaces fires rendering updates in a different way to MyFaces Trinidad. If the developer must be aware of that, odds are you won't find proficient JSF developers.

    I pointed about this one at the Web Frameworks discussion at JavaOne. It is not easy to find a Wicket developer, or a Vaadin developer. But when you find them, probability is they will be proficient, or at least above regular web developers.

    With JSF, which has tons and tons of job offers around the world, but lots of implementations and caveats, probability is that you will easily and quickly find a JSF developer to hire, but he or she won't be proficient. They will be regular developers. I'm not saying this is 100% true. Of course it is possible to find a proficient JSF developer. But with different implementations, it is hard to find one that knows all about of their tricks, tips, issues and secrets.

  6. Designers and developers roles mixed
    Oracle said it has set up JDeveloper or some other inside tool with JSF support to their web designers. Now, this is cool. You teach web designers to define templates, UIs, using the Java IDE. In the end you have the view done and all JEE devs need to do is to bind, code and run.

    This is one way of doing it. But usually, it is not the case. Most companies have Web Designers working on Mac, with Photoshop and Dreamweaver or some other WYSIWYG editor. They are great designers partly because of great tools.

    With JSF, designers and developers mix their work. Designers spend their time templating. Developers spend most of their time fixing broken templates after mixing them with JSF components. Now this, ain't cool at all.

  7. Does not improve usual web development process
    Like I said before, companies are still working with a development process based on: design, template, inject dynamic code, fix design issues, release.

    That's how Java Web development works. If you disagree, please comment on that. But I've been developing web applications for almost 8 years and that's how I see it.

    All frameworks that mix dynamic code on the HTML or some layer that outputs it, doesn't improve the common web development process. Which sucks, IMO. You have Web Designers to do all the prototype. Sometimes, your company pays to a Design shop to do that. And in the end, you have business developers fixing design issues because a pixel here or there is not correctly aligned with that right border.

    Now, there are some frameworks that address this issue quite well. Tapestry is one of them, if not the first. Then there's Wicket, which of course the best practice is to componentize the UI, but it is possible to work only with the prototype. With JSF, you have Facelets. It helps a lot, and I'm sure improves *a bit*. But the development process is beyond working with pure HTMLs and prototypes.

    With JSF, the developer does a lot of SOP - String Oriented Programming. If you are not working with a great JSF-supported IDE, you will end up doing a lot of copy-paste of Strings of method names, property names and bean names.

    Some may argue that Wicket replaces JSTL with Java. It is true. But consider this: if you are working with Wicket and you've already binded your UI, you don't have to look to your HTML again. With JSF, you must look at your ManagedBean and your page to make sure everything is correctly binded. On Wicket, new properties and methods can be added without modifying the UI, and still with JSF you must edit two files to do that. It is one approach, I know. But that does not changes neither improves the development process if you compare to Struts. GWT improves that, just as Wicket, IMO.
     
  8. Non-functional prototype
    Ok, not a big deal. But it sucks a lot when your web designer changes the UI and you must merge those changes. What if you had a functional prototype you can share with your Web Designer? Some frameworks do that. Tapestr and Wicket for example. The output is HTML, your are building HTML, your designer gives you HTML, so why not take advantage of that work done on a previous stage?

  9. Performance
    Just Google for benchmarks comparing JSF with any other Java Web Framework. The lifecycle is just huge.... :-(
     
  10. Web is fast, standards are slow
    Let's take JPA for example. How old is SQL? Since 1974. Hibernate was build based on something that it was already a standard. So it was JPA. It is reasonable to have a specification for that, and totally acceptable to work with. JPA developers won't have problems dealing with different implementations, at least if they do their job right. What about XML frameworks? Mid 90's. My point is. Some specifications are build based on something with limited scope, even though generic, or on something that is already a standard and well-know by the market.

    Now let's take the Web. Although HTML is a specification, and old, it definitely has an unlimited scope. And because of its nature, it is open to innovation and creativity. How to standardize that?! HTML5 is almost there, and we are still waiting for a specification that really improves the Web Development Process. Again, JSF2 is a huge step forward, but too late, and just like to what happened with EJB, people are now afraid of it because its previous version. And that's why people started to choose Rails, Python, GWT and other frameworks.

    Long learning curve. Slow improvements (thanks to JCP). Everything the Web does not need. Everything Agile methodologies are against to.
I did work with JSF before, and I love to be a Java developer. I have my work done with it, and I'm paid because of it. But I felt like being left behind while looking at friends building cool apps, quickly and with good quality, with other languages, other platforms. And if I want to deliver solutions with performance, quality AND speed to my customers, I will think twice before choosing JSF.

Sure it has scenarios or business strategies where JSF is the best option. If there wasn't, Oracle/Sun, IBM, Red Hat and others would not put money on that. For companies that want to make sure they will easily and quickly find a developer to replace another, to keep the work on a JSF project, then, it's a business decision.

Now, from a developer perspective, I prefer to do my projects with something non-standard, while the Web is not standardized, and my customers are not worried about that.
Contato

Email:bruno.borges(at)gmail.com

LinkedIn: www.linkedin.com/in/brunocborges
Twitter: www.twitter.com/brunoborges
Comprei e Não Vou
Rio de Janeiro, RJ Brasil
Oracle
São Paulo, SP Brasil