Showing posts with label JavaOne 2011. Show all posts
Showing posts with label JavaOne 2011. Show all posts

Saturday, October 8, 2011

JavaOne 2011 - A Tremendous Success: Blogosphere Round-up

The blogosphere is full of accounts of JavaOne 2011 and most of them are extremely positive. Peter Hendriks says of JavaOne 2011, "the Java vibe is back" and "Java is moving forward again." Cameron McKenzie says of JavaOne 2011, "Mark it up as a success." After one day at JavaOne 2011, Sean Landis stated, "There are good things happening" and "good things on the horizon." Cay Horstmann says of JavaOne 2011, "The message that I got from this year's JavaOne is that Java SE and EE are alive and kicking" and adds, "I look forward to Java One 2012." Ian Skerrett writes, "JavaOne is finished and I am leaving with a positive feeling about the conference and the Java community" and predicts "Next year JavaOne is going to be a LOT bigger." Terrence Barr observes about JavaOne 2011, "JavaOne has brought renewed excitement and energy to the Java community."

Other bloggers provided additional interesting commentary on JavaOne 2011. Juliano Viana states that he saw "the scariest Java talk I have ever been to" at JavaOne 2011. About JavaFX announcements at JavaOne 2011, Peter Pilgrim states, "Oracle have delivered on their promised, or may be it was Sun Microsystems vision, to reinvigorate the user interface on the desktop.." Al Hilwa is quoted as saying, "I would say that Java is in better strategic shape on several levels." Eric Bruno states, "I've been at JavaOne all week and the experience has been fantastic." The original set of JavaOne 2011 presentations on Parleys.com are available.

I have already dedicated a blog post to summarizing my JavaOne 2011 posts and I look at other peoples' JavaOne 2011 posts in this post. I don't look specifically reference JavaOne Conference Blog posts here because I figure their existence is fairly obvious.

Miscellaneous Individual Posts Dierk Koenig Posts Cay Horstmann Posts Adam Bien Posts Markus Eisele Posts Sean Landis Posts Juliano Viana Posts Peter Pilgrim Shaun Abram Posts Trisha's Posts Alex McGray's Posts Press Releases

Conclusion

The overall reaction to JavaOne 2011 seems to be extremely positive and I think most of us who were able to attend this year are already hoping that we will be able to attend JavaOne 2012.

By at No comments:
Labels:

Friday, October 7, 2011

JavaOne 2011 "Inspired by Actual Events" Round-up

Another edition of JavaOne has come to a close. Sitting at San Francisco International Airport (SFO) to head home seems like a good opportunity to provide a "round up" of my posts on JavaOne 2011. These are posts I wrote during the conference itself or immediately after it ended; I wrote more posts about JavaOne 2011 before the conference began.

Looking over this list of keynotes and sessions reminds me how much JavaOne 2011 had to offer. This is even more startling when one considers that each of the technical sessions above represents just one offering of many available in each session's timeslot. It truly was an information-packed conference.

By at No comments:
Labels:

Thursday, October 6, 2011

JavaOne 2011 Overall Impressions: The Good, The Bad, and The Ugly

There was much to like (and some to dislike) about JavaOne 2011. In this post, I look at my impressions of the good, the bad, and the ugly of JavaOne 2011.

Good: Announcements

JavaOne is famous for its announcements and this year's edition was full of them. Here are some I found most interesting (in no particular order).

Good: Technical Content

The technical sessions tended to be strong technically and even the keynotes generally had sufficient level of technical content. I focused on presentations involving core Java concepts, alternative JVM languages, and JavaFX, but was able to see some presentations on topics as diverse as cloud computing, JAXB, and REST.

Good: Networking and Community

There were many "big names" in the Java world present at JavaOne 2011 and it was nice to meet some of them and to see some of them speak. It was also nice to get a feel for the diversity of concerns and needs of the Java development community.

Good: Ideas to Take Home

There are too many good ideas that I want to take back home with me to play with and possibly blog about in select cases. Here are some of them, though I acknowledge now that I know I won't get to some of these anytime soon if at all.

Groovy is Increasingly Assumed Knowledge

I mentioned in my review of JavaOne 2010, "It seems to me that Groovy has either reached or is very close to reaching that point where it is no longer new or unusual to the majority of conference attendees." This definitely seemed to be even more the case this year at JavaOne 2011. I wasn't the only one with this impression: Dierk Koenig wrote, "It appears that in the mainstream, Groovy has become the default choice for dynamic programming on the JVM."

Bad: Limited Resources

The good news was dramatically increased interest in and attendance at JavaOne this year as compared to last year. The bad news is that not everyone seemed prepared for that large number. The restrooms were frequently out of paper towels and hand soap early in the week and I was only able to get the Wifi to work on a very sporadic basis.

Bad: Hotel Logistics

Many of the same negatives associated with hosting the sessions in the hotels remained issues this year because nothing was really different. I actually welcomed the opportunity to walk between the buildings to get fresh air and reinvigorate myself, but walking between the seemingly more narrow when crowded halls (especially in the Hilton) was not a positive experience in all cases. It didn't help that some attendees were more focused on their mobile device than on getting from Point A to Point B. Long conference rooms were okay for hearing and seeing the speaker, but did not lend themselves to seeing the screens that were not very far above the crowd. Because the screens are so low in many of these long conference rooms, it is difficult for attendees past the first several rows to see significant chunks of the screen. One idea that would help is if the slides were made available prior to or at the conference so that people could follow them on their laptops, mobile devices, or even printed hard copies. This would not help with the code examples shown in IDEs and on the command-line, but it would help with the slides. I noticed many people taking photographs of screens with reference details and having current access to slides would reduce the need for that as well.

Bad: The Weather

Last year, when it was the Mason Street Tent between Hilton San Francisco and Nikko Hotel, we had beautiful weather. This year, when it was the open area Mason Street Cafe between those same two hotels, we had rain and inclement weather nearly every day. Truth be told, I don't mind this type of weather as long as it's not down pouring. I like cooler weather as long as I'm not getting really wet in the cooler weather. However, there is no question that the weather dampened some of the outdoor activities. I'm just waiting for someone to blame Oracle for the bad weather.

Ugly: Overrunning Keynotes Combined With Throttled Foot Traffic

This is a particular subset of categories I've already mentioned (logistics and over-running keynotes), but the combination of these two led to a particularly ugly scene. The staff was throttling how many people could exit the Hilton Ballroom area at a time after the keynotes ended. This wasn't as big of a deal with the Technical (Opening) Keynote because people had left in large groups throughout the session from the time Mark Reinhold's presentation ended up until the actual end of the session which went well past its advertised time. This length of time seemed to distribute the exiting more naturally. A much higher percentage of attendees stayed for the entire Strategy Keynote and this led to a problem as the number of people allowed to leave was artificially throttled at the top of the escalator. It meant many people being late to the first of the technical sessions that day.

Ugly: "Queuing" for Presentations

Several of the sessions had long queues forming as either the previous session was getting out or the next session was not yet allowing entry. Sometimes these queues backed into the main hall thoroughfares. This was most problematic in the hotel (Hilton San Francisco) with the most conference room space.

Ugly: Keynotes Java Rapper Video

The looks on most attendees' faces seemed to be a mixture of disbelief and confusion. I even had people not attending the conference sending me e-mail and text messages asking what was going on at JavaOne when seeing the Java Life video. The video and lyrics are available here. It does seem to have gone viral among Java developers.

The Incidentals: Miscellaneous Observations

There were some things that happened this week that did not directly affect nor were directly affected by JavaOne 2011, but which happened at the same time and were watched by conference attendees. Apple's long-anticipated announcement of the iPhone 4s may have been slightly disappointing because iPhone 5 was anticipated, but truly sad news was received a couple days later when we learned of the passing of Steve Jobs. Jobs' unique mix of creativity and technical genius have been shown again and again via his involvement in the development of the personal computer, iPod, iPhone, iPad, and Pixar. As much as I loathe iTunes (the software, not the site), I must admit that it helped changed the music industry and the way we all purchase and listen to music.

I occasionally speak at conferences and so try to pick up good practices for my own presentations from speakers that I watch. I also try to observe which practices are not so effective and either avoid them myself or remove them from my own presentations. One such observation that I realized again this year and seem to realize at every conference I attend is the importance of limiting the time "spent in the IDE." I know presenters do this because we're all comfortable with IDEs, but the truth is that it is easier to see code in slides when the slides are carefully prepared, have color syntax highlighting, and focus only on what's important. Slides are often easier to see than IDE text in these large rooms of JavaOne. It takes a lot more work for a speaker to put code into slides with a nice presentation like that given in the IDE, but I think it's one of the best things a presenter can do for his or her attendees. If this is not possible, the next best thing s to make very quick excursions to the IDE (not long enough to need to sit down) and to use a very large font and make it obvious what one is looking at.

Conclusion

Although JavaOne 2011 had its good, its bad, and its ugly, the good dramatically outweighed the bad and the ugly. Although it's good that it's over because I don't know how much more I could have crammed into my mind and I want to go start trying some things I learned, I will miss it as well. If JavaOne 2012 is held simultaneously with Oracle OpenWorld again, it will be scheduled for September 30 - October 4, 2012.

By at 1 comment:
Labels:

JavaOne 2011: REST and Hypermedia as the Engine of Application State with Standard Java APIs

For my last technical session of JavaOne 2011, I wanted to attend something "easy" with a short title because of the mental fatigue and crammed brain resulting from four days of blistering rate of technical information coming my way. With that in mind, I chose to walk across the hall from Hilton San Francisco's Golden Gate 6/7/8 to Golden Gate 3/4/5 for the presentation "REST and Hypermedia as the Engine of State with Standard Java APIs" (24609). Although I have worked with REST and JAX-RS/Jersey, the abstract of this presentation caught my eye. In addition, I believe that HATEOAS may be the least understood, most confusing, and most misused term (or unused portion) in all of REST-dom.

The presenters of "REST and HATEOAS with Standard Java APIs" (Mattias Hellborg Arthursson and Kalle Stenflo, both from Jayway) stayed away from using the acronym HATEOAS because no one seems to know how to pronounce. Because I'm typing it rather than saying it, I'm using the abbreviation from here on out. Their agenda showed items to be covered including REST, JAX-RS, RESTful JAX-RS ("true REST with hypermedia"), and "Generic JavaScript Client."

Stenflo briefly discussed the history of REST based on Fielding's famous dissertation. He mentioned that the "architectural style" of REST had been misused and hijacked by several to be a structural style. Stenflo then went on to discuss the basics of REST with definitions of terms like "resource." He also discussed the HTTP "verbs" and stated that "REST is about using the web the way it was intended." Stenflo discussed "self-descriptive messages" that "contain all information needed to complete a task" (this statelessness is what makes horizontal scaling easier).

Stenflo had multiple slides titled "HATEOAS: Hypermedia as the Engine of Application State." This concept allows for "discoverable resource interaction" and "allows resources to evolve over time." Stenflo explained that the consumer is provided with the correct link for a given resource.

Arthursson stated that if you're doing REST with Java, "you should probably be using JAX-RS." Arthursson introduced some of the key annotations that JAX-RS provides such as @Path, @GET, @POST, @PUT, and @DELETE. He feels (as do I) that the JAX-RS is one of the best JSRs in recent years. The Expert Group for JAX-RS 2.0 is about to publish a draft and the new version will focus on improvements requested from the community. These features include a common client API (that would be very nice) and "support for hypermedia" (JAX-RS currently does not support HATEOAS)

Until JAX-RS 2.0 implementations are available (and the spec is not even written yet!), we need a way to handle hypermedia in Java-based REST style applications. Arthursson introduced some approaches from RESTeasy Atom link, Jersey linking, and "purely annotation-based" approaches that are "more readable, "more versatile," and require DTOs to have "knowledge of hypermedia." His understanding is that the JSR Expert Group is leaning toward the annotation-based approach as well.

Arthursson introduced jax-rs-hateoas as an open source JAX-RS 1.x extension. The README for jax-rs-hateoas states:

JAX-RS-HATEOAS is a small extension to JAX-RS to enable hypermedia in JAX-RS 1.x applications.

Adding hypermedia to your existing application is easily done in four steps:
* Extend HateoasApplication (or JerseyHateoasApplication)
* Add a RequestContextFilter in your web.xml (enables the framework to get access to the full request URIs)
* Add @Linkable annotations to all methods that should be linkable.
* Use HateoasResponse instead for building responses with HATEOAS links.
The normal Response methods (ok, created, entity, etc.) will now return a HateoasResponseBuilder.
The HateoasResponseBuilder contains methods to easily add links to your responses:
** link(String linkId, Object... params) - adds a link to the referenced linkId
(as defined by an @Linkable annotation).
** selfLink(String linkId, Object... params) - adds a link to the referenced linkId with a 'self' rel
(rather than the default rel defined in the referenced @Linkable annotation
** ...etc

Arthursson covered these steps in his slides and then moved to an IDE (SpringSource Tool Suite) to show a live example. His examples demonstrated the ability to use @Linkable from jax-rs-hateoas to provide hypermedia in responses (such as HateoasResponse). The jax-rs-hateoas project seems pretty easy to use and it was stated that it's pretty small and is designed to allow developers to customize their hypermedia as necessary.

Following Arthursson's IDE-based demonstration, Stenflo took back over to demonstrate a JavaScript client that is a "single-page JavaScript application." He stated that it's useful for a developer to test out his or her REST API. The demonstrated client works on hypermedia returned to the client.

The speakers referenced several projects that attendees might find useful in Jayway's Github respository. They specifically referenced rest-assured in addition to jax-rs-hateoas and also stated that the demonstrated JavaScript client is available in the demos section (there is also a core download).

A good question was whether XML was supported in jax-rs-hateoas (only JSON was demonstrated). At this point, only JSON (the "cool stuff") is supported, but they acknowledged that XML needs to be supported.

This was an interesting presentation and looks like a promising solution for bridging the gap between today and JAX-RS 2.0 in terms of appropriately using HATEOAS in REST-based applications using JAX-RS. The project is still young, but could end up filling a niche in the Java/REST world. In the end, it's likely that JAX-RS 2.0 will make this obsolete, but that could be years from now.

By at 2 comments:
Labels: , ,

JavaOne 2011: Serialization: Tips, Tricks, and Techniques

I returned to the Hilton San Francisco for the last two sessions of JavaOne 2011. The first of these was Steve Poole's (IBM) "Serialization: Tips, Tricks, and Techniques" (24606) in Golden Gate 6/7/8. This fit with one of the "themes" of the sessions I attended this year: a focus on core Java principles such as class loading, HotSpot JVM performance tuning, JVM bytecode, and garbage collection. This was probably the biggest "theme" of my session choices with the other most common theme being alternative JVM languages. Since the beginning of Java, Java serialization has been the source of some of Java's greatest mysteries and secrets and has provided easy fodder for interview questions. No further evidence of the trickiness of Java serialization is needed than the fact that Josh Bloch devotes an entire chapter of Effective Java (Chapter 11 in the Second Edition) to five items covering its use.

Poole started by talking about IBM's Java Technology Edition Version 7 (IBM's Java 7 JVM) which was made generally available on 19 September 2011. Poole has been the IBM representative on JSR 270 (Java SE 6) and JSR 337 (Java SE 8). His "recent work focus" has been IBM and OpenJDK and IBM's Java 7 implementation.

Poole had a mostly filled room and he observed that "he wouldn't be here" for the last presentation of the conference (in this room). He stated his talk would cover "basic use and abuse of serialization as personified by 'implements Serializable'." Poole stated this his presentation focuses on "traditional serialization," but that much of it is equally applicable to "other serialization stream technologies."

Poole made the point that Serialization matters because it "underpins" numerous technologies such as RMI, EJB, and JPA and "is becoming more important in Cloud-related technologies." His slide provided a basic definition of serialization: "Serialization converts between data held in object graphs and a linear stream of bytes." The same slide provided an important overall piece of advice: doing serialization first is much easier than retrofitting it on later. Poole covered the basic requirements of a Serializable class.

Poole talked about the basic methods used in the act of serializing and deserializing. He pointed out that the readObject method cannot read in data that was never written out (writeObject method). Poole recommended treating readObject() like a constructor, which makes sense, of course, because both approaches create instances of a given class. This means, for example, that one should not call overridable methods on the same class from a class's readObject method because object construction may still be ongoing. Poole's advice is, "Don't think of readObject() as a method, but think of it as a constructor."

Poole also warned that every bit of data brought in via readObject is valid. All incoming data should be treated as untrusted and not valid until verified. Poole stated that he saw numerous problems resulting from assuming good data on deserialization. You cannot assume that any data being deserialized was created by the corresponding and compliant writeObject() method.

Poole showed problems switching from a primitive boolean to a reference type Boolean in terms of serialization and de-serialization. He talked about serialVersionUID. Poole referenced Bloch and introduced the "Serialization Proxy Pattern," which he described, "The Serialization Proxy Pattern provides a stand-in object that gets serialized instead of the main object." This approach separates business data objects from the objects responsible for serialization and deserialization. The best way to avoid these issues is to stay out of the Serialization business altogether ("opt out"). When that's not possible, the Serialization Proxy Pattern allows one to at least decouple Serialization issues from business data classes. Poole said another benefit of the Serialization Proxy Pattern is related to dealing with versions.

An important observation that Poole made is "'implements Serializable' and being serializable are not always the same thing." He recommends use of tools to help, including FindBugs, appropriate Javadoc tags (@serial, @serialField, and @serialData), and specifying serialVersionUID. Poole added the recommendation to ensure that an object's serialized data is consistent via writeObject() synchronization and use of 'transient' to eliminate duplication. He also recommended defending against synchronization deadlocks. Poole stated that it is helpful to serialize as little as possible and there are techniques for doing this. One is to use "short field names" (an advantage of separating serialization from business data with Serialization Proxy Pattern!) and not serializing duplicate/derived data.

A Poole concluding slide that "having a good understanding of the art of Serialization is a necessity - even if you never intend to use it." He warned that Seriallization will continue to be of "importance to Java technology directions."

By at 3 comments:
Labels: ,

JavaOne 2011: Rocking the Gradle

I've found myself using Groovy for all types of development issues and for different stages in the Java development lifecycle. In the area of builds, however, I've mostly stuck to using Groovy scripts within Ant build files or to using AntBuilder in Groovy scripts. In addition, I have wanted to expand my knowledge of the great Groovy ecosystem by working with products new to me such as GroovyFX, Griffon, and Gradle. With that in mind, I left the Hilton San Francisco for my only time during this last day (all four other sessions in the Hilton) to attend "Rocking the Gradle" (21881) in the Market Street conference room in Parc 55.

The presentation was decently attended, but far from full. This is a good thing because it made it easier to see the low screens. Ken Sipe (Gradleware CTO) began his presentation by asking who was using Ant, Maven, and Gradle. Over half of the respondents responded to Ant, probably about one-fourth to one-third responded to Maven, and a handful responded to Gradle. Sipe said that Ant (+Ivy) is used by control freaks who want to control all aspects of the build while Maven is used by those willing to go with standardized build conventions.

Sipe told the audience about a short book on Gradle that is available called Building and Testing with Gradle. I also noted that there is an online Gradle Cookbook and there are some Gradle Tutorials. Sipe noted that one of the mistakes people make when learning and first trying Gradle is to coerce examples they find into their own situation.

Sipe stated that Gradle is a DSL built upon Groovy that has the same Apache 2 license as Ant/Ivy and Maven. Sipe stated that "Gradle is declarative" and "specifies what" rather than the "how." Sipe stated that Gradle allows developers to create a model in the project. Sipe said that, "in the end," you probably should know Groovy if you're going to get into Gradle for the long-term. He pointed out, however, that there are many good Groovy-based tools coming out, so the implication is that learning Groovy is a good thing anyway. I agree.

Sipe showed several examples of how easy it is to begin using Gradle for simple dependency mapping. One of the powerful mechanisms he showed was use of Groovy closures to provide a conditional specification of a dependency using onlyIf and dependsOn properties. Wow!

Another impressive Gradle example that Sipe showed was setting of version information in the Gradle script using a call to Java's Date for a timestamp. The easy integration of Java/Groovy made this concise and powerful and clearly showed an advantage of not needing to specify a "script" in XML. Sipe talked about Gradle's being plug-in based and showed some examples of this. One such example was using Jetty Plugin. Other plugins include the War Plugin and custom plug-ins.

Ken Sipe stated there is no better tool than Gradle for multi-project builds. He then went onto talking about integration with Ant and Maven. Gradle implements with Maven repositories and there is "early work" on using Maven POMs directly rather than having Gradle-specific POMs. Gradle has really tight integration with Ant. You can reference any Ant task with ant.. You can also specify that all operations done between braces (via Groovy closure) are being invoked against Ant. This tight integration with Ant makes it easy to migrate Ant builds piece by piece.

Sipe said that using standard plugins often causes troubles for people new to Gradle. Custom plugins allow capture of "corporate defined conventions." Deviations from the corporate standard become obvious. Sipe also talked about Gradle's conciseness and being Groovy. Gradle can do anything Groovy can do because it is Groovy. That last point appeals to me. It has always been limiting in Ant to not be able to simply use Java whenever I please.

During his presentation, Sipe referenced the book Continuous Delivery.

I need to invest some more time into playing with Gradle, but Sipe's presentation has led me to believe it is worth the time and effort. Gradle appears to have tremendous potential for building and managing dependencies and its easy integration with Groovy and Ant also make it attractive. Hopefully, the GA release of Gradle 1.0 will occur in the near future.

By at 1 comment:
Labels: ,

JavaOne 2011: Do You Really Get Classloaders?

After the Java Community Keynote on Thursday morning, I went to Plaza A/B in the same Hilton San Francisco to attend "Do You Really Get Classloaders?" (19220). We heard about Parleys for JavaOne 2011 in the Java Community Keynote and, coincidentally, a version of this presentation (Devoxx) is available on Parleys. The PDF of another version (Jazoon) of the presentation is available as well (there is also a Parley's video for the Jazoon version).

I knew going into "Do You Really Get Classloaders?" that my understanding of class loaders was far from complete. I had battled class loading issues enough in the past to know they are one of the more tortuous parts of Java and can be a scary experience, but I am far from an expert on their intricacies. My goal in attending this session was to improve my knowledge of class loaders and have a better understanding of how to debug issues related to class loaders.

The decently sized room was standing-room only once the presentation began. The interesting thing was that the front rows were packed and the back rows were largely empty at the beginning. I attribute this to the fact that it is so difficult to see the bottom 1/3 of the screens in this room if you're not pretty close because of too many people sitting in between you and the screen. It ended up filling up and the vast majority of the attendees stayed until the last few minutes.

The speaker, Jevgeni Kabanov, is the creator of JRebel and he stated that a free (for non-commercial use) version (JRebel Social) can be acquired. As part of working on JRebel, Kabanov had to learn many details about Java class loading ("learned a lot more about class loaders than we wanted to") and planned to share some of those lessons in this presentation. He cited presentations "Java is not type-safe" (1997) and "Dynamic classing Loading in the Java Virtual Machine" (ACM) for more details.

Kabanov started with basics of class loading. Classloaders are primarily a runtime concept that were motivated originally by Java applets. Classloaders enabled loading of one class at a time, which was important in the day of dial-up modems. This origin explains many of the positive and negative aspects of class loaders. He stated that Java tends to load classes as late as possible.

Class loaders exist in a hierarchy and every class loader has a parent class loader. The parent class loader is "consulted first" to "avoid loading same class several times." In Java EE Web Module, however, "local classes are searched first" in case container ships larger version that should be overridden by provided lighter version.

Kabanov showed a simple Java servlet example that threw a NoClassDefFoundError. One of the attendees speculated that this was due to the class, Util1, not being on the classpath. Kabanov asked how one finds out what is on the classpath. He showed a "neat little trick" that works on several servers: (URLClassLoader(getClass().getClassLoader()).getURLs()

Whenever you load a class, you can also access it as a Resource (class.getClassLoader().getResource()). Kabanov showed using this to identify location of class or extraneous map. He also talked about using javap to find out about structure of a class. He used this to show why a NoSuchMethodError was encountered in his example.

Kabanov's next example showed a funny ClassCastException: "ClassCastException: Util3 cannot be cast to Util3". The problem manifest here is that you cannot cast an instance of the class from one classloader to an instance of that class in a different classloader. The reason for this is that a class is uniquely defined by its classloader. This did not used to be the case, but that was a huge security hole called out by the previously referenced article "Java is not type-safe." The class loader is considered part of the class's identifying information so two classes with same name and same package are "different" if in different class loaders. Kabanov was able to cause this exception in this case because the Web class loader loads its own version rather than delegating to its parent.

Kabanov demonstrated an LinkageError ("loader constraint violation") by removing a class cast. This too was covered in the "Java is not type-safe" paper and the point is that it's not just a class cast issue. In this case, the JVM internal implementation is trying to implicitly cast the classes and they are still not the same due to different class loaders.

In another example, Kabanov produced an IllegalAccessError. This turned out to be a case of the same class name with a different packages. It is an example of the problem of "more than one class found" category which includes LinkageError, ClassCastException, and IllegalAccessError.

Kabanov stated several times that one of the best ways to identify some of these class loader issues is use of -verbose:class on the JVM from the command line (Java command launcher, java). As he covered the different categories of class loader issues, he looked at various other tools to determine the problem. These include use container-specific logs and use of the Unix/Linux find command. Kabanov also highlighted the freely available Eclipse Memory Analyzer for hunting down memory leaks (this tool came up at last year's JavaOne as well).

The Tragedy of the ClassLoaders is that every object holds onto the entire class loader and this is what makes it tricky. It is difficult to build tools to detect and resolve leaking of class loaders. Kabanov has a blog post on web environment class reloading called Reloading Java Classes 301: Classloaders in Web Development — Tomcat, GlassFish, OSGi, Tapestry 5 and so on.

Kabanov says that "the modern way" is to have a classloader per JAR, to have all class loaders as siblings, and to have each JAR explicitly state which packages it imports and exports. Kabanov discussed several ways forward including in-app updates. He referenced LiveRebel to be used for making small updates cheap.

This was an excellent presentation that helped me realize that a few of my practices related to resolving class loader issues are appropriate and also provided me with several new approaches to resolving future class loader issues. It is obvious that Kabanov is familiar with the subject and it is also obvious that his having presented this presentation multiple times previously has paid off in a smooth, entertaining, and enlightening presentation. My guess is that his JavaOne (and other conferences) presentation "Do You Really Get Memory?" is worth seeing. Although he had reasonable charts for his classloader presentation, much was added in his interactive dialogue and IDE source code examples and my guess is that the same is true for his memory presentation.

By at 1 comment:
Labels: ,

JavaOne 2011: Java Community Keynote

There are three Diamond Sponsors of JavaOne 2011 and each gets an opportunity in a JavaOne 2011 keynote to address the conference attendees. Intel had their opportunity in the Technical (Opening) Keynote, Juniper Networks had their opportunity in the Strategy Keynote, and today IBM had its turn in the Community Keynote. Just as Intel opened the Technical Keynote and Juniper Networks opened the Strategy Keynote, IBM opened the Java Community Keynote (37780) on Thursday morning in Hilton San Francisco Grand Ballroom A/B.

Despite this being the latest starting (by 15 minutes) of the three keynotes, this keynote saw the latest arriving attendees. I don't know if this is due to the Appreciation Event last night, due to the effects of a long week full of activities, or due to people deciding to come late with knowledge that the sponsor gets the first portion of the keynote. My suspicion is that all three apply.

Jason McGee (Distinguished Engineer, Chief Architect WebSphere Cloud Computing, IBM Corporation) started his "Cloud.contains(Java);" presentation by stating he was going to talk about two of his favorite things: "Java and the cloud." He said he would talk about "making Java and the JVM more suitable for the cloud." McGee identified two "cloud challenges for Java." These are the "layer of liars" ("dynamic platform behavior is the 'new normal') and "increased density critical to cost of ownership." He explained that "cloud economics" works based on a high level of sharing, leading to the increased density.

McGee talked about modularity being an important cloud innovation. He also stated that sharing (memory, classes, code, JVM) being a necessary cloud innovation. McGee talked about potential associated with the ability to share data between Java virtual machines. McGee talked about better sharing in the operating system with appropriate secure and managed data exchange. McGee then moved onto discussing sharing in the middleware. This has been done, but McGee said assistance is needed from the JVM to run different applications with different levels of trust together.

McGee talked about Balanced GC, "a new scalable large heap GC in Java 6.26 and Java 7." This garbage collector helps deal with large heaps. More details regarding IBM's balanced garbage collector can be found in Java Performance Tuning Tips for August 2011 and in When to use the Balanced garbage collection policy.

McGee moved onto discussion of scaling. He talked about elasticity being achieved via creation of more instances of the resources being run. McGee talked about other characteristics of Java servers that are cloud friendly and then talked about IBM's implementation of the "JEE Web Application Pattern."

McGee talked about "IBM's long commitment to Java" and said that his focus today is just one in a long list of contributions that IBM has made to Java. He said Java is already useful and IBM wants to make it even easier to use. He said IBM has shown itself committed to starting and leading Java open source projects. He cited IBM's joining OpenJDK as an example of IBM's involvement with open source Java.

After showing an Apple logo with white apple on dark background and having a moment of silence in honor of Steve Jobs (a nice, deserved tribute), Sharat Chander (Oracle Principal Product Director and JavaOne Program Committee Chairperson), talked about over 400 technical sessions being offered throughout this week. Mike DeNiccola, John Rose, and Patrick Curran were recognized for their efforts related to Java Community Process (JCP). Chander gave a plug to Oracle University and then introduced Donald Smith, Directory of Product Management for Java Platform Group.

Chander and Smith said this was the first ever Java Community Keynote. Smith then invited Martijn Verburg (London Java Community), John Duimovich (OpenJDK), Deepak Bhole (OpenJDK), Stephen Chin (Silicon Valley JavaFX Users Group), and Bruno Souza (SouJava) onto stage for a community discussion and acted as the monitor. Smith, a Canadian, attempted to get Canadian attendees to be as loud as the Brazilian attendees. The typical pre-keynote announcement to turn off mobile devices was immediately rescinded this morning because they actually wanted mobile device participation in this Java Community Keynote panel discussion.

There were several community polls conducted on a live basis. The first question was which version of Java developers were using most frequently. This was followed by a question regarding frequency of attendance at Java User Group events. Another poll question was developer involvement in OpenJDK. I kept hoping to a controversial question regarding Android to add some excitement. Other poll questions asked why developers don't attend user groups more often and if the pace of "Java moving forward" needs to be faster, slower, or stay the same.

Some of the questions tweeted during the community panel discussion involved JavaOne 2012. In particular, someone requested return to the Moscone and another requested Metallica as the Appreciation Event musical artist.

In the portion of the panel discussion regarding Java moving forward, Stephen Chin stated that "JavaFX is built for the cloud." Chin talked about a "huge groundswell of support around Java 7." Verburg told the Java community that they need to help fix things, "You need to help Oracle and other vendors build cool stuff you can use."

There was discussion about challenges of getting people involved in user groups. Chin said the Silicon Valley JavaFX Users Group streams sessions and using Parleys. They have more members using their online resources than attending meetings and he believes this is the future of user groups. Chin also mentioned benefiting from local access to "big names."

I thought that the concept of a Community Keynote was interesting and had potential. However, I noticed that a small but fairly steady stream of people flowing out of the Ballroom A/B as it proceeded. I believe there are a couple reasons for this. First, some of the things being discussed have been blogged about, written about, and spoken about repeatedly and frequently and are readily available to anyone with Internet access. Second, I think it is easy for us to become so enamored with idealism that we sometimes forget that many developers just want to learn new technical information and frankly aren't all that interested in a community discussion between panel members. Still, I thought it was an interesting idea and was worth attending. If I had to rank this panel among "pieces" of the three keynotes at this conference, it would be somewhere in the middle in terms of interest and relevance.

Chin had previously mentioned Parleys in conjunction with his user group and this became the focus of a latter portion of the Java Community Keynote. Stephan Janssen told the audience that slides, video, and demonstrations can be synchronized. He stated that twenty talks will be released today (enough for the airplane ride home) and about 160 will be released by the next JavaOne.

Several Duke's Choice Award winners had an opportunity to talk about their product. I liked the quote related to jHome, "There is life beyond database applications for Java EE." The jHome example uses a fairly complete Java EE stack along with jQuery and Arduino.

"Three-quarters of the Java Posse" (Google's Tor Norbye was conspicuously absent) were featured next. Carl Quinn, Dick Wall, and Joe Nuxoll asked who preferred various versions of Java, various JDK 8 features, and various alternative JVM languages. They then moved onto Java 9 desired features. These "surveys" decided the winner based on which received the loudest cheering. The three attending members of the Java Posse then acknowledged the Duke Award Winners by having them stand up and stated they'd be featuring them on the Java Posse in the future.

Chander concluded the Java Community Keynote with some observations about community participation and the "Java Life" video."

By at No comments:
Labels:

Wednesday, October 5, 2011

JavaOne 2011: JavaFX 2.0 with Alternative Languages

Stephen Chin and Dean Iverson presented "JavaFX 2.0 with Alternative Languages" to end the third of four technical JavaOne days. The presentation was held in Nikko Ballroom III and was another surprisingly lightly attended presentation. There were probably fewer than twenty in attendance and I suspect that other sessions at the same time may have had lighter than normal attendance as I heard several developers talking about going to dinner or other events after the last session time.

Chin briefly reviewed JavaFX 2.0 and talked about the ability of JavaFX 2.0 to "embrace all JVM languages." He also highlighted that "JavaFX Script is no longer supported by Oracle" though Visage is the "open source successor to the JavaFX Script language."

The presenters provided a slide with a "Hello World" style of JavaFX application that was a class definition with only the static "main" function defined.. They showed a slightly more complex example with the static "main" function and with an overridden version of the start(Stage) method. They then showed an example, still in Java, of using the Builder approach.

Binding (Chin called it "the biggest JavaFX Script innovation") has survived from JavaFX 1.3 to JavaFX 2.0. Changes in both directions are allowed and lazy invocation is supported for performance optimization.

Chin discussed Observable Pseudo-Properties that support "waiting for changes to properties" and there will be future closure support for this. The slides showing code for this were "animated" to show what each piece of syntax does. The code was "icky" due to use of anonymous classes because closures won't be available in Java until JDK 8 (summer 2013). Chin promised to show JavaFX making this easier already.

Groovy and JavaFX

Iverson believes that Groovy provides the easiest way to use JavaFX. He is one of the two people primarily behind GroovyFX. Iverson outlined some of the features and benefits of Groovy including the ease of porting from Java and the heavy use of Builders. Iverson's "Java vs. GroovyFX DSL" slide showed much more concise and more fluent syntax for the GroovyFX DSL example than for the straight Java example.

GroovyFX provides a SceneGraphBuilder. The advantages of Groovy's Builder style were obvious as Iverson showed the typical name/value pairing syntax for specifying attributes of a circle. The 'bind' keyword is used to explicitly find to properties.

Iverson showed a code sample "that is not hard, but is tedious" that demonstrated implementing properties in Java for a Person class. Iverson showed a GroovyFX annotation @FXBindable that makes all that tedium go away. I was really impressed with the ability to use Groovy closures in GroovyFX to handle the event listeners much more succinctly. Iverson showed tedious code necessary in Java to use the TableView ("a great control") and then showed how much simpler it was in GroovyFX. Iverson showed similar improvement in conciseness and expressiveness for layout when comparing GroovyFX to Java use of JavaFX. Iverson showed a slide that demonstrated several of the effects supported in GroovyFX and added that GroovyFX supports FXML. He stated that all basic controls are supported in JavaFX. Finally, Iverson stated that GroovyFX supports Griffon, which he described as similar to Grails for the desktop.

Clojure and JavaFX

Chin introduced Clojure and provided a brief background on this functional language. Because of its fewer side effects, it is optimized for high concurrency. Chin emphasized that its syntax "looks nothing like Java!" One of the slides, "Clojure Syntax in One Slide," compared Java syntax to Clojure syntax. Chin talked briefly about Clojure macros, but did not show any of them.

Iverson's examples using GroovyFX to integrate Groovy with JavaFX. Chin's code example for Clojure had no intermediary and was direct Clojure code for JavaFX interaction. The Clojure example employed doto to interact with Java. Chin said this could be a lot "cleaner and nicer" if someone who knows Clojure would build a little DSL or wrapper similar to what's available for Groovy and Scala.

Scala and JavaFX

Chin is a fan of Scala with JavaFX. He talked about advantages of Scala such as static type checking, closures, declarative characteristics, and support of type-safe DSLs (implicit conversions, operator overloading, and advanced language features). Chin talked about using implicits to extend another class (he used java.lang.String as an example) to add a method in a typesafe manner. Like Groovy, Scala supports operator overloading via specially named methods.

As was shown in the Groovy section of the presentation, the "Java vs. Scala DSL" slide showed significant improvement in conciseness and expressiveness between from Java to Scala. There was a feigned debate regarding whether Groovy/GroovyFX (fewer lines) or Scala/ScalaFX (fewer characters) was better, but the "agreement" was that either are easier to read and write than Java.

ScalaFX supports a bind operator. The Chin example showed this binding and also demonstrated use of an aggregation function (max()) along with conditional expressions and compound expressions. It is much more difficult in JavaFX 2.0 than it was in JavaFX 1.3 to properly bind to the entire path used in a bind expression, but ScalaFX makes this easier by wrapping the JavaFX 2.0 select API. Another ScalaFX example also showed use of Scala closures for "100% type-safe" event listener handling.

Other JVM Languages

Other JVM languages covered in a single slide ("Other JVM Languages to Try") were JRuby, Gosu, Mirah, and Fantom. Chin pointed out that, like Scala, Fantom runs on the CLR. Chin showed a slide with Fantom sample code that has been based on Fantom's Swing support. It is non-existent at this point, but ishow it would likely look. Fantom and Gosu were covered in an earlier presentation today.

Project Visage

Chin showed an example using Project Visage (JavaFX 1.3/JavaFX Script). He also talked about it being able to make Android native calls. He had a slide called "Visage is JavaFX Script++" and says that many things have been added to JavaFX Script. Visage supports default parameters, has new literal syntax, has a null check (.!) operator (null safe by default, opposite of Groovy), and has bindable maps coming soon as a built-in feature. Chin had a slide outlines other advantages of using Project Visage with JavaFX.

Conclusion

Chin and Iverson concluded by saying that JavaFX applications can be written in Java, but is also "usable in alternate languages." There is "improved support" using DSL libraries like GroovyFX and ScalaFX or via a dedicated UI JVM language such as Visage. The presenters covered significant territory in this presentation including JavaFX, Groovy/GroovyFX, Scala/ScalaFX, Clojure, Fantom, and Visage.

By at 1 comment:
Labels: , ,

JavaOne 2011: The Diabolical Developer (Redux)

There was an hour between sessions before the beginning of Martijn Verburg's "The Diabolical Developer (Redux)" (25303) in Divisidero in Parc 55 Hotel. I wanted to attend this presentation for three reasons: the abstract appealed to me, I had read good things about it, and I wanted to meet Martijn after trading several blog comments with him. Incidentally, there is a recent Kevin Farnham video interview of Martijn available at Java.net.

Here is the abstract for this presentation:

The Diabolical Developer hosts this in(famous) session in which he challenges everything the modern Java developer holds to be good and true. The Java developer today stands in a sea of APIs, frameworks, best practices, software development methodologies, and more. The developers who sent mankind into outer space did not have all of this. Makes you think, doesn't it?

The session takes you through practical steps (the right attitude, self-learning, using the right tools, sticking to Java 1.4, and the like) you can take to free yourself from the chains the industry has put on you. You will leave empowered and will get back to doing what you love the most, hacking Java code.

This irreverent presentation was just as the abstract would lead you to expect. With great sarcasm and tongue-in-cheek, Martijn challenged some of the trendiest software development technologies and methodologies and called into question some of the "best practices" software development preaches. The gist of this presentation is that developers should "think about the problem, think about what they're doing, and use common sense." Martijn proves this point through use of outlandish (sometimes) statements that consist of "half-truths, outright lies," and some things he actually believes. He left it to audience members to decide which of his points fell into each category and in this way encouraged developers to think for themselves rather than blindly following what has been preached and sold to them.

I am intentionally not repeating all of Martijn's points that are either half-truths, outright lies, or things he truly believes in because part of the appeal of his presentation is the delivery and the shock value. Instead, what I plan to do in this post is pick a few of his points that I believe (and at least for me) fall into the half-truth or "I believe" categories.

This presentation was packed and, fortunately, was going to be offered again in the subsequent section. I don't think anyone left once it started except for the one guy who left and came back. Martijn warned attendees at the beginning of the session that they should leave if they were Agilists, Software Craftspeople, Oracle employees, or "sensitive." I found it humorous that Martijn invited anyone who wanted to leave to do so after explaining that his presentation would have none of the popular topics (JVM bytecode, Clojure, or Scala) of this conference.

Martijn talked about vi being the only editor one needs to know. I know that this is only a half-truth because I know that he uses NetBeans. That being stated, I have blogged before on advantages of using vi (or derivatives) and definitely find times when basic knowledge of vi commands has proven handy and productive.

Martijn "recommended" several practices as part of mortgage-driven development. These practices tend to be the same as those for resume-driven development (or "CV++ development" in the UK) and involve things like hoarding information, obfuscating code, and using terse variable names with no comments.

Dilbert.com

Although many of Martijn's points were intentionally shocking or extremely worded, he also made some "serious points." For example, after making fun of Agile's worst purveyors, he established the real point: agile is "not a silver bullet." Brooks told us there is no silver bullet and I still believe that to be the case regardless of whether we're talking about agile, SOA, cloud, or any other trendy topic. Martijn added that the numerous "grand technologies behind Agile" had been ruined by folks selling services, books, and the like. He described Agile as "just a set of techniques" that "in New Zealand we call 'common sense.'"

Another Martijn serious observation was that software craftsmanship is about attitude and can be easily summarized without books and consultants: "Just care about what you're doing."

On the theme of thinking for oneself, Martijn stated, "Those can't code, teach coding. Those who can't teach coding, write a book about coding. Those who cannot finish a book about coding, speak at conferences." Given that he is working on a book and speaking at a conference, it is likely that this falls into the half-truth category. The more serious point he did make is that it is easy to get so busy doing all those other things that one has no or very little time for actually developing code.

One of my favorite "recommendations" from this presentation was to place rear-view mirrors on monitors. The idea here is to be able to quickly come up with an excuse to leave when a Seagull Manager is approaching. He explained that the Seagull Manager is the manager who "flies in and craps all over the place."

Dilbert.com

Martin observed that "copy and paste is fine" for effect and then in a more serious tone stated that it is fine for prototypes to be rapidly created and can be refactored out later. This was an example of how, in some of the cases, Martijn would intentionally say something shocking and then back it up with practical thinking that is much less shocking.

The point of Martijn's presentation seems to have been to get software developers to challenge conventional thinking and to embrace those things that do work for them in their situations and jettison anything that does not apply to them or their situations. In light of this, he prefers the term "better practices" over the term "best practices." His concern about "best practices" is that the term implies we've reached the peak in that area and have no more work to do.

Dilbert.com

One of the statements that I wholeheartedly agree with Martijn on (whether it was half-truth or fully believed) is: "Being a software developer is one of the greatest, most creative things you can do." Although Martijn's "recommendation" to look in the mirror each day and tell yourself, "I am awesome," may be a little extreme, I do believe a software developer needs to be confident.

Another interesting observation made during this presentation occurred when Martijn asked how many in attendance in this packed room had a real, legitimate need for cloud computing. One individual raised his hand. Martijn restated what I believe we were all thinking: vendors and consultants continue to sell us concepts and technologies that we don't really need. This was a stark reminder of the importance of thinking for oneself and avoiding vendor-based architectures.

I've long been a fan of contrarian viewpoints because they do challenge groupthink and the Lemming Effect. Martijn's presentation was aimed at challenging long-held generalized thinking. Developers who attended seemed to be entertained by Martijn's extreme presentation, but I'm sure most of them had at least one favorite practice or mantra challenged and now have the opportunity to reflect on the validity of that practice.

By at 1 comment:
Labels:

JavaOne 2011: Every Last Nanosecond: Tuning the JVM for Extreme Low Latency

Sunny Chan's presentation "Every nanosecond counts" (20262) was offered in Hilton Golden Gate 6/7/8 beginning at 1 pm on Wednesday. This was another very well attended session that was standing-room only (and sitting on the floor in the aisles room only) from the beginning and throughout his presentation (not all presentations that start well attended end well attended). Chan stated that "Java is extensively used within Goldman Sachs" (his employer) and he works with Java SE and Java EE. He previously worked in IBM JVM development.

Chan stated that some of the issues Goldman Sachs has faced using Java include low latency and high throughput. He said he would be talking about "reducing of start-up latency" and "improving performance by tuning" (memory access and large pages support). Chan also set the level of the session at more advanced than simply running profiling tools.

Chan said that many developers say things like "I want it really fast" when what they really want is "high throughput." He talked about "low latency" meaning "reducing the time between receiving the information and response to the information" (time to receive, time to process, and time to send data). He defined "high throughput" as focusing on "the amount of the data you can process in a given amount of time." Chan had a bullet that noted that high throughput does "not necessarily mean reducing the latency." Chan cited some causes of increased latency as garbage collection and inefficient code or use of resources and listed some others as well. Developers need to ask themselves if they care more about request/response times or amount of data transferred. Chan's experience is that most developers really want higher throughput.

Chan talked about ways to tune Java to reduce latency. These include understanding your application by using profiling tools such as hprof and VisualVM. He also recommends knowing your operating system (including the operating system characteristics and tools) and your hardware (including interaction of memory, CPUs, and caches) as a beginning point. Chan also reminded attendees to have benchmarks on own software and to not base decisions on others' benchmarked products.

In his slide "Start up latency," Chan stated that "JVM is a complex piece of software" and he talked about the relatively lengthy start-up time to get it up and running. This leads to a condition he describes in another bullet: "Component start-up could cause significant latency." He then talked about "biased locking." The Java SE 6 Performance Whitepaper describes biased locking:

Biased Locking is a class of optimizations that improves uncontended synchronization performance by eliminating atomic operations associated with the Java language’s synchronization primitives. These optimizations rely on the property that not only are most monitors uncontended, they are locked by at most one thread during their lifetime.

An object is "biased" toward the thread which first acquires its monitor via a monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations can be performed by that thread without using atomic operations resulting in much better performance, particularly on multiprocessor machines.

See the Java Tuning White Paper for an example of using biased locking. See also related command-line options. Chan mentioned an under-documented command-line option for HotSpot called BiasedLockingStartupDelay (one of set of options recommended for running high performance server applications).

Chan moved onto discussion of the JIT compiler. He talked about using -Xcomp to "force JIT to compile everything" in HotSpot rather than its normal behavior of "initially Java bytecodes are interpreted by the JVM." He also referenced Ahead-of-Time (AOT) compilation in some JVMs. He referenced the HotSpot options -XX:+PrintCompilation and -XX:+PrintOptoAssembly for seeing what the JVM is doing. Chan explained that hsdis must be compiled from OpenJDK's source code to use the PrintCompilation option. Chan showed how printing the goings-on of the JIT compiler can help identify latency issues.

Chan recommended that "most of the time you should leave tuning to the JVM developers!" and enjoy "Java abstracting the programmer from the hardware." He would later have this as part of his conclusion as well ("You can trust them").

Chan then moved onto Linux "standard profiling tools" called Oprofile and perf. He stated that some of the commercial ones are even nicer.

Chan talked about the "performance benefit of large pages," a fairly common theme that I've heard in multiple presentations and keynotes at JavaOne 2011. Chan described this concept as "changing the page size to 2M [from 4k on x86], so the number of translations is reduced." This leads to faster memory access. Chan stated that applications with large heaps are likely to benefit from large page sizes and that benefits of large page sizes depend on hardware being used.

Chan ended with a slide with several references. These references include What Every Programmer Should Know About Memory, OProfile results with JIT samples, Perf JIT Interface, and Java and Large Page Support.

I really enjoyed Sunny Chan's presentation, but he covered so much material that I'd like to see it again. His slides are good (and he said he plans to make them available), but he added a lot of value in the verbal descriptions, so it would be best viewed with both his slides and his presentation. Unfortunately, I don't think it's being recorded, but hopefully I'm just not aware of its recording.

By at 2 comments:
Labels: ,

JavaOne 2011: Introduction to the JavaFX Scene Builder

After grabbing lunch from the Mason Street Cafe, I headed to Hotel Nikko's Nikko Ballroom III to attend "Introduction to the JavaFX Scene Builder" by Eric Le Ponner and Jean-Francois Denise (both of Oracle). I was a little surprised that this decently attended presentation wasn't much more full given the announcements this week that Java Swing will see no further enhancements and that the to-be-open-sourced-and-standardized JavaFX is the Java client of choice for the future. Attendees were only sitting in the front half of the room and there were plenty of empty seats between those present in in that front half. There may have been fifty of sixty attendees.

Poller initiated the presentation with descriptive information about he and his co-presenter. He then went into JavaFX Scene Builder's goals and benefits. JavaFX Scene Builder has multiple goals: "help designers and developers build JavaFX-based user interfaces", put "JavaFX 2.0 in action," and help developers "explore and learn about JavaFX objects." "Key Benefits" of the JavaFX Scene Builder are closely related to the goals and include "simple and intuitive interface" that "makes the tool productive even for non-programmers."

Denise spoke about new features of JavaFX 2.0. He mentioned the FXML format (not to be confused another FXML) and likened it to Adobe's MXML and Microsoft's XAML (and I note like OpenLaszlo's LZX). FXML is generated by serializing Java Objects as XML text. A JavaFX 2.0 application can be written either "fully coded in Java" or "partly coded in Java." The latter (partially coded in Java) is accomplished by using Java for logic and FXML for the scene graph.

As one would expect from a typical presentation on a GUI builder, much of this presentation focused on demonstration of JavaFX Scene Builder. The dragging and dropping of GUI elements or "widgets" was not particularly new or exciting (although it's nice to have available for JavaFX development), but I was more interested in seeing the generated FXML. Incidentally, Oracle provides an Introduction to FXML document for learning FXML.

In Denise's first demonstration of using the tool, he used JavaFX Scene Builder to design the Scene Graph and then used the IDE for almost everything else. The basic gist of this approach is that one uses JavaFX Scene Builder to generate FXML and then that generated FXML is accessed and used from a Java IDE such as NetBeans.

Poller showed a different demonstration. His demonstration showed off more fine-grained control of CSS presentation style. The good news is the ability to use standard CSS style syntax to specify JavaFX element appearance and to even specify by hand CSS syntax when necessary. The only negative I saw was that there was still some typing involved rather than relying on name completion when typing style information into a text field. Poller showed the CSS code generated and it looked like CSS one would write directly. He even created a rectangle with rounded corners (the "Holy Grail" of HTML/CSS presentation) as part of this demonstration. The reflection effect was also impressive and was all done graphically. The demonstration also involved setting values of opacity and that effect was also pleasing.

In a different demonstration, Poller showed how easy it was to graphically rotate an element. He then showed the ability to anchor multiple copies of the same object in different ways and how the anchor is maintained when the image is made larger. It was much more easily done than one would do by hand to specify this appearance control.

Poller gave us some task-aways. JavaFX Scene Builder supports "simple drag and drop positiiong of GUI elements," it is a "graphical FXML editor, it supports "strong mapping of JavaFX 2.0 APIs," supports setting and previewing "JavaFX properties and effects," and supports "CSS setting and previewing."

There were some great questions and comments in the Q&A section, which the presenters left appropriate time for. One attendee expressed exactly what I was thinking: the earlier JavaFX Scene Builder is released the better as it should save lots of time developing scene graphs. Another attendee asked a question I was wondering myself, "Will JavaFX Scene Builder be standalone only or would it be an IDE plugin?" The answer is that JavaFX Scene Builder is a standalone application, but it will have nice integration with NetBeans. Another attendee asked if JavaFX Scene Builder would be expanded to fully cover JavaFX and if custom components would be supported. It sounds like plans are to fully cover JavaFX presentation capabilities in JavaFX Scene Builder and there is a possibility of support for custom components in the future.

An attendee commented that the JavaFX books available for sale on site at the conference are all for JavaFX 1.2. He asked if there were enough differences between JavaFX 1.2 and JavaFX 2.0 to make it not worth it to purchase the JavaFX 1.2 books. The answer was clear: wait and buy a book on JavaFX 2.0 because the changes are significant and much of the JavaFX 1.2 stuff is "deprecated."

As was stated earlier this week, Oracle will be very soon issuing a private release of JavaFX Scene Builder followed by a public release anticipated for early 2012. I can hardly wait to get my hands on the JavaFX Scene Builder and start playing with it.

By at 3 comments:
Labels: ,
Subscribe to: Posts (Atom)