Monday Sep 24, 2012

Join Me at JavaOne!

JavaOne 2012 is less than a week away! If you've already made plans to be there, you're probably getting pretty excited about it already...and if not, what are you waiting for?!?

Before I get to the session information, I want to point out that qualified students get free admission to JavaOne, so if you are (or know) a CS or IT (or other tech-leaning) student who might like to attend, follow the link and start making plans. There is so much there to learn and experience.

I'm happy to say I'll be a small part of the festivities. I'll be leading the following session:

CON3519 - Building Hybrid Cloud Apps: Local Databases + The Cloud = Extreme Versatility

In this session, learn how to design and develop applications that leverage both local storage and the cloud, maximizing the strengths of each. Using NetBeans, JavaServer Faces 2.0, GlassFish Server technology, JavaFX 2, Oracle Database, and Evernote, rapidly create prototypical applications that can be deployed in various environments and scaled up/out with enterprise cloud solutions. 

As a contributor to the JFXtras project, I also hope to attend the following "Birds Of a Feather" (BOF) session led by Gerrit Grunwald and Stephen Chin:

BOF5503 - JFXtras Super Happy Dev BOF

JFXtras, the open source JavaFX control and extensions project, is back for JavaFX 2.0. In this session, you will learn about the latest changes in JFXtras 2.0, including new components, controls, and features that integrate with the JavaFX 2.0 libraries. Expect to meet the JFXtras core team members as well as other interesting client RIA implementers and developers. Now that JavaFX is coded in Java, a few server-side hackers may even be let in the door.

If you're there, please stop by and introduce yourself! And to follow along with my J1 travels or keep in contact afterward, please follow me on Twitter or connect via G+ or Facebook (links in panel to right). Hope to see you there, but either way, keep the Java flowing!

All the best,
Mark 

Tuesday Jun 05, 2012

Quick Fix for GlassFish/MySQL NoPasswordCredential Found

Just the other day, I stood up a GlassFish 3.1.2 server in preparation for a new web app we've developed. Since we're using MySQL as the back-end database, I configured it for MySQL (driver) and created the requisite JDBC resource and supporting connection pool. Pinging the finished pool returned a success, and all was well.

Until we fired up the app, that is -- in this case, after a weekend. Funny how things seem to break when you leave them alone for a couple of days. :-) Strangely, the error indicated "No PasswordCredential found". Time to re-check that pool.

All the usual properties and values were there (URL, driverClass, serverName, databaseName, portNumber, user, password) and were populated correctly. Yes, the password field, too. And it had pinged successfully. So why the problem?

A bit of searching online produced enough relevant material to offer promise. I didn't take notes as I was investigating the cause (note to self), but here were the general steps I took to resolve the issue:

First, per some guidance I had found, I tried resetting the password value to nothing (using () for a value). Of course, this didn't fix anything; the database account requires a password. And when I tried to put the value back, GlassFish politely refused. Hmm.

I'd seen that some folks created a new pool to replace the "broken" one, and while that did work for them, it seemed to simply side-step the issue. So I deleted the password property - which GlassFish allowed me to do - and restarted the domain. Once I was back in, I re-added the password property and its value, saved it, and pinged...success! But now to the app for the litmus test.

The web app worked, and everything and everyone was now happy. Not bad for a Monday.  :-D

Hope this helps,
Mark

Monday May 07, 2012

Looking Through the Telescope From the Big End: Four Small Java Developments that Pack a Punch!

There are a LOT of exciting developments in Java, almost on a daily basis. Most of them make a big splash, and for good reason! But sometimes, it's the little things...

There have been a lot of small developments in Java that are pretty exciting, too. I'll pick out four of my favorites - each at a different level and/or stage of development or detail - and explain why they're a big deal. Let's get started!

Home automation

I had the privilege of watching Vinicius and Yara Senger give a presentation at Jfokus (available below at Parleys.com) on Java EE and home automation. The Sengers developed the jHome platform and run it on GlassFish, controlling Arduino-based appliances in their home, office, and boat. I won't give away all the spoilers, and it isn't Java end-to-end...but the Sengers are demonstrating a compelling, fully open source (hardware and software!) package for Java working in harmony with even the tiniest of devices.

Robotics

FIRST, or "For Inspiration and Recognition of Science and Technology", was founded by world-renowned inventor Dean Kamen. In his words:

"Our mission is to inspire young people to be science and technology leaders, by engaging them in exciting mentor-based programs that build science, engineering and technology skills, that inspire innovation, and that foster well-rounded life capabilities including self-confidence, communication, and leadership."

FIRST's vehicle for doing this is robotics. Teams of various ages use available technology components and their brains to develop and program robots to compete in some pretty tricky challenges. This isn't Robot Wars (no Real Steel destructive matches here), but it's just as engaging - for the teams and spectators alike.

The 2012 FIRST International Championship was held in St. Louis, MO, USA, and teams representing several countries participated. I was able to attend for awhile - with an event like this, you just can't see it all! - and chanced upon a team in the pit area with a homemade sign saying "We use JAVA!". I was directed to the 15 year-old programmer who proudly informed me that they use NetBeans and Java to program their robot. We had a nice conversation, and I was left with the realization that Java's original "embedded" mission is still being realized in ways that we don't often think about.

Raspberry Pi

Simon Ritter recently posted about his work with the Raspberry Pi and JavaFX 2. I had seen others relate their victories getting OpenJDK onto the little Pi, a small-but-capable computer the size of a deck of cards...but Simon (and those who provided assists in whatever form) took the bar and threw it up onto the roof. It won't win any supercomputer awards (well, not alone anyway!), but the Raspberry Pi's small size and low price now make a host of formerly-unrealistic uses possible. Even before much optimization is done, JavaFX 2 is already running. If you've ever migrated existing software (of any kind) to a new platform, you know that that first "clean" run can be elusive. I can't wait to see how far we can take this...just as I can't wait for my pre-ordered Pi to hurry up and get here!

Harmonization of Java ME, SE

Henrik Stahl was on the Java Spotlight podcast recently (link below) presenting a clear vision for the harmonization of Java Micro Edition (ME) and Standard Edition (SE). The devil is in the details, of course, but here's the good news:

1) There is a plan
2) The plan makes sense
3) The plan is being worked...diligently!

Without getting into those details or the challenges surrounding them (API synchronization, Jigsaw, etc.), a modern, consistent set of APIs and a modular architecture should excite Java developers wherever they may fall along the spectrum.

The Bottom Line

It's an exciting time to work with Java at any level, and that includes in the crevices where small and/or embedded devices often lie hidden from view. If you haven't already been involved in "Java in the small", check it out. And if you have a favorite I've missed, drop me a line or comment below! If you like it, chances are the rest of us will, too.  :-)

All the best,
Mark



free counters


Sunday Apr 29, 2012

Performance Test: DriverManager vs. DataSource

I was troubleshooting some well-traveled Java code the other day and hit an intriguing set of circumstances. The original developer(s) of this code -- a web application using JSP/servlets -- had written a data wrapper construct using DriverManager. After several upgrades of JDK and JVM, some minor cracks were starting to show.

We tried doing a direct transplant of DataSource-based code into the wrapper mechanism, effectively a one-for-one swap of the minimum number of lines of code without any real refactoring. Yes, I know...not a good idea for the long-term. But one has to start somewhere.  :-)

Interestingly, performance tanked. When things like that happen, it's time to get curious and dig deeper.

Why DataSource?

The DataSource approach to data connectivity brings numerous benefits with it (connection pooling, distributed transactions, etc.), but does it also carry a hefty performance penalty? I had never heard that it did. Either way, it's always good to do a little first-person testing to verify/refute findings. So off we go!

Testing Methodology

I put together a pretty simple test and ran it several times to factor out normal variations in environmental conditions. Using NetBeans, I created a plain-vanilla web application, sans frameworks. Next, I asked NetBeans to generate JPA entities from some tables in our database, and then an EJB (see this recent article for a refresher on connecting a basic EJB to underlying data via a DataSource) to provide the DataSource-based baseline. I then created an EJB that used DriverManager to build a connection and SQL statements for comparison.

Oh, and one last necessity: I created a couple methods to capture start/stop times using System.currentTimeMillis() for a timekeeper. That covered all the essentials.

And the Winner Is...

Well, there really wasn't a runaway winner strictly from a performance perspective. Results varied from run to run, but these two horses were neck and neck, often trading the lead by only a few milliseconds in consecutive runs...which is great news, considering that DataSource offers so much more and yet manages to retain the expected level of performance.

The bad news? Well, it's clear I have a lot of rework to do on this old code.

Sigh.  :-)

For more fun with Java, click here to follow Mark on Twitter.

Thursday Apr 19, 2012

Basic Bean Building: How to Quickly Create a JSF Managed "Look-up" Bean

If you're called upon to build a JSF application (large or small), NetBeans is a great tool to help you gain traction, and fast. I've mentioned previously how much I like the ability to do a quick first cut by creating your data structures and using NetBeans to generate a basic web app as a starting point. You go from nothing to working web application in short order, albeit a bit bare-bones. Still, what a great time-saver!

Let me toss out a few reminders and disclaimers. First, I'm a firm believer in rapid, iterative, and thoughtful development. No "paralysis of analysis" allowed, but OTOH, each step should be considered carefully as you go. Plan, execute, evaluate. Lather, rinse, repeat.  :-)

Second, build from small to large. Plan ahead, but make things work on a small scale and build out. This goes hand-in-hand with point #1, but it bears mentioning separately.

With those points in mind, I created a small sample project for use in this and future discussions: The Mighty Bean Coffee Company. Java is a wonderful thing in almost any form, so why not double our pleasure?

For the first iteration of our new project, I created an initial set of tables in a new MySQL database. These are the ones we'll be considering on our quest to create a JSF managed "look-up" bean:

Next, I created a new Java Web project, Web Application in NetBeans called MightyBeansWeb. Defaults were fine for our purposes here with the exception of selecting JavaServer Faces under Frameworks.

With the project created, I right-moused on MightyBeansWeb in the tree browser, chose "New Entity Classes from Database", and made the connections to the data source. Selecting the two tables modeled above, NetBeans provided us a couple of nicely-formed entity classes: Customer.java and CoffeeOrder.java.

Creating the JSF pages was also a snap. Right-moused again on the app, chose "New JSF Pages from Entity Classes", selected the classes and specified destination packages, and clicked finish. Et voila! We now have a working JSF web app. Go ahead, try it out. I'll be right here when you get back.  :-)

(Side note: Please feel free to a) update the toString() methods for more meaningful contents - this will come in very handy later! - and b) to refer to our recent article NetBeans, JSF, and MySQL Primary Keys using AUTO_INCREMENT to enable primary key auto-generation within MySQL.)

"That's great!" you say. But wouldn't it be nice to see which customer we've selected for our order? That brings us to the topic of this article. Let's whip up a look-up bean and make that happen now.

Right-mouse once more on the web app and choose "New JSF Managed Bean". Pick a name (I called this one "CustomerLookupBean") and a package and click finish. No need to do anything else on that panel since we're using Java EE 6.

Opening the class, we see it has annotations for @ManagedBean and @RequestScoped which serve our needs nicely. We just need to add a couple of very small things to wrap up our bean-work.

Since EJBs are non-reentrant, we can simply inject an instance of EntityManager into our lookup bean by adding the following lines to the class definition:
    @PersistenceContext(unitName = "MightyBeansWebPU")
    EntityManager em;
Clicking on the warnings in the left column prompts you to let NetBeans fix the imports. Yes, please!

Next and finally, we need to create a method to return the desired customer, something along the order of this:


This method issues a named Customer query using the ID provided and returns a single result. Since createNamedQuery returns a generic object, we cast it to what we know is coming back to us (a Customer object), then return the customer's full name. Not pretty, but good enough for a first cut.

Editing the appropriate list.xhtml file to display the customer's name instead of number is as simple as replacing <h:outputText value="#{item.customer}"/> with <h:outputText value="#{customerLookupBean.getName(item.customer.id)}"/> to query and receive the full customer name, taking us from this:

To this:

"Pretty" comes later, but this is a start. Any thoughts, comments, or questions? Please drop me an email or comment below!

All the best,
Mark

About

The Java Jungle addresses topics from mobile to enterprise Java, tech news to techniques, and anything even remotely related. The goal is to help us all do our work better with Java, however we use it.

Your Java Jungle guide is Mark Heckler, an Oracle Java/Middleware/Core Engineer with development experience in numerous environments. Mark's current work pursuits and passions all revolve around Java and leave little time to blog or tweet - but somehow, he finds time to do both anyway.

Mark lives with his very understanding wife, three kids, and dog in the St. Louis, MO area.



Stay Connected

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today