Recently in Java Category

(This is a posting I started a while back (on my brother's b-day in May) but didn't publish at the time... don't remember why.)

[Edits:

• Added Jun Heider's materials on run-time resource profiling (Day 3, Session 2)
• Added Ryan Phelan's slides on Pixel Bender (Day 3, Session 4)
• Added Lafferty and Frishberg's slides and an example on custom ItemRenderers (Day3, Session 4)
• Added Sanchez' slides on Degrapha (Day 1, Session 2)
• (Über Edit) John from 360 Conferences has uploaded all of the presenter slides from 360|Flex Indy that he could get his hands on here. There are 33 of them, at last count. Thanks a million, John.
• Added Laura Arguello's slides from her (excellent) Mate session (Day 2, Session 5)]

As you've probably guessed by now, if you missed 360|Flex by your own choice, you're kind of a... well, a loser. Many of the best presenters, mentors, open-source community leaders and trend-setting Flex developers were there, pouring their knowledge out in exchange for a hotel room and a 360|Flex "speaker" t-shirt. (If the room was in a train car, then just maybe it's a fair trade.)

One of the worst things about 360 (yes, I'm about to complain here, apologies to Tom and John) is that since there are generally 5 session going on at once, you're going to miss something. (I'll give you a second now to get over it.) Some things you'll never, ever get back (look through your high school yearbook for some quick examples). Fortunately, I have compiled a quick list of presenter materials that didn't make it onto the USB key. I will update this in the next few days as more stuff things trickles in.

I've listed these by day and session. (Note that I'm not counting the keynotes in numbering the sessions.)

Day 1

Session 1

Assert Yourself (FlexUnit 4) -- Michael Labriola (ably assisted by Jeff Tapper)
Slides

Session 2

Degrapha Declarative Graphics Framework - Juan Sanchez
Slides

Session 3

Structured Log testing - Renaun Erickson
Missed Points

Another Mapping API...Not! - Mansour Raad
Slides

Session 4

Any Which Array But Loose - Michael Labriola
Slides

Day 2

Session 1

Creating our first i18n (internationalization) Flex application - Oğuz Demirkapı
Slides

Flex Server Lib - Andy Powell
Slides

FLEXperience - Putting the UX in Flex -- Joe Johnston
Slides

Session 3

How Not to Code Flex Applications - Jeff Tapper
Slides

Session 4

Developers are from Mars, Designers are from Venus -- Chad Udell
Slides

Session 5

Building an AIR Video Recording Spy Camera with Motion Detection -- Rich Tretola
Slides

Breaking Down your Application with Mate -- Laura Arguello
Slides

Day 3

Session 2

Flex Profiling by Example - Jun Heider

Slides and source

Session 3

Merapi: What's Next -- Adam Flater
Source announced at 360|Flex

Session 4

Bending and Flexing with PixelBender - Ryan Phelan
Slides

Custom Item Renderers - Lafferty and Frishberg
Slides Example

That's all for now. Check back later in case more stuff pops up (it surely will).

Methinks that sometime soon, the good folks over at IBM will be kicking themselves. Hard.

When I heard that IBM was trying to acquire Sun, it seemed like a no-brainer. Even if a little part of their motivation was to spite Microsoft, IBM has long been a driving force behind Java's successes. In recent years, they've spearheaded the very successful Eclipse project, acquired Rational, continued to invest in Websphere... So, to have Sun and IBM under the same banner just seemed to be the perfect union between very different but nonetheless compatible companies.

Well, it wasn't meant to be. After IBM dropped negotiations, Sun Microsystems was left at the altar, wondering what had happened.

Caught you on the rebound

The bouquets from the cancelled IBM/Sun wedding hadn't even faded when Oracle entered the scene and, for a paltry 10 cents more a share ($9.50 vs $9.40, or 1.06% difference), swept up a darling of the industry that had been reeling since the "dot com" bubble burst in the early 2000's.

This unexpected acquisition is a great example of how a company can leverage its strengths (e.g. solid product, reputation, cash reserves) to build up a foundation for further success. In this case, given the level of trust that people (customers and potential customers) already have in their DBMS, I can easily imagine Oracle developing and packaging Oracle-branded turnkey hardware+software DBMS solutions à la Google Search Appliance.

Whether you're talking about a rack-mounted cluster of servers or a single box, they will be able to deliver and support integrated solutions featuring Sun hardware, Solaris and the latest version of Oracle. Just brand it all as an Oracle product, set up a clear (subscription-based?) fee structure and start printing money. If they do it right, Oracle may well have hit a home run with this acquisition.

Et tu, Java?

As for the Java angle, well, Oracle is already closely integrated with Java (see: Java stored procedures in Oracle), so on the technical side they'll be working in known territory. What remains to be seen is whether they will be able to increase Java's market share and what they will do with fledgling initiatives such as JavaFX.

I'm also particularly curious to see how IBM will react on the Java front. I can' t imagine them moving to a scorched earth policy and trying to sabotage the progress that Java has made in recent years, but even if they just lose some of their zealousness, it could damage the Java market overall. I personally believe that without IBM's support over the years, Java would never have had the level of success it has enjoyed. Oh well, we'll find out soon enough.

Congratulations, Oracle. Now go forth, be fruitful and multiply.


As always, thank you for reading and I invite your comments on this topic.

I was searching for something else and came across this interesting round-table discussion on the state of RIA development, circa September 2007. The host, SYS-CON, selected a good range of experts who made many interesting points vis-à-vis RIA development.

To put the discussion in context: this was shortly after the announcement of JavaFX at JavaOne, shortly before Flex went open source and before the production release of the Silverlight SDK. AJAX was still considered a pretty exotic bird and therefore dominates a good part of the early discussion.

Topics of discussion include (in no particular order):

• Open source in the RIA marketplace (dual licensing?)
  
• A good amount of discussion on AJAX
• The Silverlight Alpha SDK releases of the time (1.0 and 1.1)
• The (then recent) release of JavaFX... to mixed reviews
• Do Silverlight and JavaFX have a shot at dethroning Flash/Flex? (Jury still out... presumed lost.)
  
• That old whipping boy: search engine optimization with RIAs ("But can Google index your RIA?")
  
• Security in RIAs

In one interesting segment, the always (refreshingly) opinionated Yakov Fain makes some good points about choosing an enterprise RIA technology. Specifically, he makes the case for Java (server) + Flex (client) citing the fact that you often inherit whatever OS infrastructure your client already has in place, so you would do well to use cross-platform technologies. All the same, he adds that it would be a disservice to your clients to fall in love with a particular technology. He therefore leaves the door open to the possibility of JavaFX overtaking Flex on the client. All the same, he discounts .NET on the server side, since it doesn't play nice outside of the Windows platform.

It's amazing how fast things change in the development world. It's equally amazing how we are still discussing/disagreeing on many of the same issues nearly two years later. Anyways, I personally enjoyed listening to the discussion... perhaps you will, too.

Check it out here.

Flex apps are beasts that thrive on a healthy serving of server-side XML. How exactly you go about feeding any given app depends on your client's environment and practices, as well as your skill set and comfort level with the different preferred technologies.

My personal background lies mainly in Java development and the server-side technologies I have used most often are SOAP and servlets (i.e. plain old servlets, Struts and Spring). While I can acknowledge the value of SOAP, pay me a buck for every time I've heard someone complain about the overhead of creating/using SOAP-based services and I'd be rich enough not to be writing this. On the other hand, using servlets to satisfy the voracious appetite of a healthy Flex app has its own draw-backs.

I've suspected for some time that there is a more elegant, more lightweight way to write Flex-friendly XML-producing server-side Java code. I was therefore excited when asked to explore the world of Java RESTful web services during the lead-in to a new project here at 4Point. What follows is a summary of the many promising things I have learned in the past few days -- things that have led me to ask: "Is it finally time to scrub out SOAP?"

REST in a nutshell

REST stands for "Representational State Transfer", but frankly, the name doesn't really say much about what it really is. REST is a means of exposing a resource to outside interaction through a combination of a URI and an HTTP method (i.e. one of POST, GET, PUT and DELETE). These methods are mapped (roughly) to the classic CRUD operations, allowing you to create, read, update and delete data.

	HTTP		CRUD
	POST		Create
	GET	-- Equivalent -->	Read
	PUT		Update
	DELETE		Delete

In order to invoke an operation on a REST resource, you simply invoke the appropriate URL using the appropriate HTTP method ...and voilà!

I've been in this business for a few years now and I've been programming (in some form or other) since around 1986 (hello, BASIC!). Whereas in the past (see: University) I've been able to sit in front of a screen for 18 hours a day with only my contact lenses as protection, I've recently run into some issues that have made me re-examine how I treat my globes. Specifically: during successive business trips to a client site in Chicago, I came down with very unpleasant cases of conjunctivitis (also, see this write-up on HealthyOntario).

For starters, I've decided to look at how I've set up my development tools. I need to find the best, clearest, most ocularly soothing font for editing code in Flex Builder and elsewhere.

Eyeballing the best possible font

I've come across this fine site by Trevor Lowing which provides a collection (with clever examples) of different code-friendly "mono-spaced" fonts. It puts forward the following "good programming font criteria":

1. Crisp, clear characters
2. Extended character set
3. Good use of white space
4. 'l', '1' and 'i' are easily distinguished
5. '0', 'o' and 'O' are easily distinguished
6. Forward quotes are easily distinguished from back quotes (ideally with a "mirrored" appearance)
7. Clear punctuation characters, especially braces, parentheses and brackets

The list seems pretty complete to me, though I might add "thick enough for viewing on LCD screen", since some fonts seems downright Olsenish for my tastes...

Setting text editor fonts in FlexBuilder/Eclipse

If you're a Flex Builder/Eclipse user, here is how you change the font used for editing files:

Go to Window > Preferences
From there, go to General > Appearance > Colors and Fonts
Select Basic and double-click on "Text Font". The font settings dialog will pop up.


Make sure to have an editor open, so that when you click on "Ok" and then "Apply", you will see the font changing in the background. This will allow you to try a number of fonts until you get the settings just right.

Your take?

I plan on trying out new fonts in the coming weeks so I'd be interested in finding out what font you use for coding/scripting. What font size? What display configuration (size, single or dual display) and screen resolution?

Thanks for reading!


Taylor

Much has been made about ActionScript 3 (AS3) being a fully mature object-oriented language on par with older languages like Java, C++ or SmallTalk. I can't say that I agree, but I can attest to the many syntactical similarities between Java and AS3. Those similarities can be very misleading, though, since they can make you unwary of fundamental differences bwtween the two languages.

Here are a few key differences between JAva and AS3 that I have discovered:

Flex Object Equality

In Java, developers quickly learn the difference between the "==" operator and a call to an object's equals() method. In Flex, there are two equality operators, "==" (normal equals) and "===" (memory address equals). When dealing with primitives, things are pretty straight forward. If, however, you are dealing with more complex objects, you may want to consider using the built-in object comparator method ObjectUtil.compare().

Have a look here for more details: http://danielroop.com/blog/2007/09/02/actionscript-30-object-equality/

Variable "Block" Scoping in Flex

In Java, the location where a variable is declared makes it easy to determine the scope within which that variable will be visible. If a variable is declared within a for block, for instance, that variable is invisible once you get past the curly bracket at the end of the for loop. Not so in Flex. Variables within a block are visible to all of the function within which they are declared, even outside of the block they are in.

Therefore: do not re-use variable names in a given Flex function or you will eventually get burned.

Useful reference: http://marxsoftware.blogspot.com/2008/10/no-block-scope-in-actionscript.html

Cast Operator

In Flex, casting an object to a Class type is done using the "as" operator.

var someVar:ClassTypeA = new ClassTypeA();
var someOtherVar:ClassTypeB;
someOtherVar = someVar as ClassTypeB;

Flex equivalent to Java instanceof operator

Flex's equivalent to the Java "instanceof" operator is the "is" operator. As far as I know (which isn't saying much), it seems to behave the same as its Java counterpart.

if (someVar is ClassTypeA) {
    trace("someVar is an instance of a ClassTypeA.");
}

// Assuming that the cast succeeds
if (someVar as ClassTypeB is ClassTypeB) {
    trace("This should always be true.");
}

That's pretty much all that comes to mind for the time being, but there's surely more to come later. Please feel free to add your own Java/Flex differences in the comments section.