Birds of a Feather Sessions
Birds of a Feather sessions will take place on the evening of day two. These are smaller, intimate and informal sessions that take on the feel of group discussions or "roundtable" discussions on topics of particular interest to the Java community.
These sessions are for you, the attendee. They are a time for you to hang-out with like-minded people and pick their brains, share your knowledge, agree, disagree, and simply learn something new from someone new.
Suggestions for BOFs :
We want to hear from you on what topics you're interested in. Send your thoughts, input, suggestions regarding BOFs.
Submit a BOF Proposal:
In an effort to keep these sessions informal and interactive we ask that you do not present slides. Submit your bio proposal. Please include discussion title, what attendees will learn and why the subject matter is of importance to attendees.
TheServerSide Java Symposium Wiki is back! Ask questions or post comments regarding any of our BOFs below:
Ajax Security Smackdown
Ted Goddard, Senior Software Architect at ICEsoft Technologies, Inc.
Bring your white hat and arrive armed to assault the security architectures of five popular Ajax frameworks: Dojo, DWR, GWT, Zimbra, and ICEfaces. This BOF will proceed by taking each framework in turn: following a brief overview of the Ajax framework at hand, the discussion will lead into an exposure of its "attack surface". Then the floor opens to all participants to point out flaws and evaluate possible attack vectors, looking at development practices, the exposed network API, script injection, cross-site scripting, unauthorized data mining, SQL injection, and more. You will have an opportunity to share your Ajax security concerns with fellow framework and application developers and will gain an appreciation for the risks presented by different Ajax strategies.
Developer Perspectives on OS Licensing
Donald Smith, Director, Ecosystem Development, Eclipse Foundation
Have you ever had a manager or legal department slow down your project why they try to figure out software licensing issues? Or have you ever witnessed a flame war between two open source groups claiming each others licenses are horrible, yet not really understood what the big deal was? Would you like to be able to confidently defend why a particular license is OK for your development project? Have you ever, or do you plan to, write code for an open source project? If you answered yes to any of these questions, this BOF is for you.
There is nothing worse than quickly finding the right tool or framework for the job, only to have managers and “legal” spend weeks, months and years trying to ensure that the software is used legally. Donald BOF starts off with an overview of intellectual property, trademark, copyright and patent terminology. He then reviews the most important grants and sections in any software license, commercial or F/OSS. Finally, he compares and contrasts many popular F/OSS licenses including Apache, Eclipse and GPL. The point of the discussion is not that any F/OSS license is “better” than another; the point is being able to choose and defend which one is best for your project depending on your situation.
Dynamic Script Languages
Frank Cohen, Founder of PushToTest, Author, FastSOA
Java 6 introduces native support for dynamic scripting languages (JSR 223, scripting languages and Java technology.) This BOF session brings together leaders, users, and critics from the Jython, Groovy, PHP, Ruby, and many other scripting camps for an exchange of ideas to develop a common understanding of the state of the art and practical examples of using dynamic scripting languages to solve problems.
Embedded Domain-Specific Languages: Raising the Level of Software Design
Glenn Vanderburg, Independent Consultant
Ruby and JRuby developers are gaining tremendous benefits from a style of development that was almost unknown just two years ago: embedded domain-specific languages. They help keep software simple and adaptable, and can be built in any dynamic language.
Who should attend: Programmers who want to use DSL techniques to improve the design and maintainability of their software.
Recommended general knowledge: Attendees should be skilled programmers. It helps to know a little Ruby, but it's not essential.
You will learn: What embedded DSLs are, see some real-world examples, learn the basics of how embedded DSLs are written in modern languages, and also some of the potential pitfalls.
Java Generics for Evolution
Maurice Naftalin, Co-author of Java Generics and Collections, Director, Software Development, Morningside Light LTD.
Migrating an enterprise application to a new language version is rarely easy. It will definitely not be easy at all if the new language features affect the way in which library APIs are used, so that code making library calls has to be kept in line with the migration cycle of the libraries themselves. In this talk, Maurice shows how the design of Java 5 generics eased this problem, with some practical examples of how client and library can interoperate when either one alone has been generified. We'll also consider other consequences of the design decisions that make this possible.
Java EE Transactional Models: Verification and Performance Testing of Business to Resource Transaction Mappings
William Louth, Product Architect, JXInsight
This session introduces the transaction management capabilities within the Java EE platform exploring in detail the potential performance, resource capacity, and transactional correctness issues in mapping application business transactions to resource transactions via application interfaces (JTA& JTS), deployment descriptors (JEE & Spring), and application architectures (Rich Clients). Transaction chopping will be explored in detail with the emphasis on JMS, JDBC, EJB3, and JCA.
Java Persistence: Avoiding Common Pitfalls and Solving Common Problems
Michael Bouzinier and Olivier Caudron, InterSystems Corporation
The latest breakthroughs in Java Persistence technologies enable programmers to create persistent applications without the help of database experts. However, even experienced Java developers can encounter unexpected problems trying to make their application persistent. In this discussion, Michael and Olivier explore some of the common pitfalls to avoid and common problems that can be encountered when creating Java application persistence. They review simple examples of Java programs, each using just a few lines of code. Then, the audience will be asked what they expect as the output of the program. When that output is not exactly as expected - Michael and Olivier will discuss what went wrong. This will enable them to discuss the merits of different solutions to solve each scenario. Touching upon issues like declarative data validation, referential integrity and optimistic concurrency by way of discussion and sharing sample Java code demonstrating the use of Jalapeño and Hibernate.
Today, making Java application objects persistent can be simple, but achieving successful persistence strategies for your real-world applications is not,- join this BOF to discover why.
Memory Leaks in Java™ Applications: Different Tools for Different Types of Leaks
Gregg Sporar, Technical Evangelist on the NetBeans project, Sun Microsystems
Not all memory leaks are the same. Some eat away at memory slowly over time. Others grab huge chunks of memory all at once. What is common for most of them is that they ultimately cause the virtual machine's heap to run out of space. A large variety of tools provides a high-level view of a Java™ application's memory usage, but not all of them are appropriate for doing the detailed analysis needed to find the cause of a memory leak. Depending on the type of memory leak, some tools are more appropriate than others. This BOF session examines some of the tools and techniques available and uses example memory leaks from real-world Java applications.
Gregg shows how to track down a memory leak where multiple object instances of the same class are created over time, some of which are the source of a leak and others of which are not. Gregg also examines how to debug a memory leak where only a single object instance is the source of the problem. Each of these examples involves a brief examination of the source code and a demonstration using a monitoring/profiling tool. Comparisons are done between the two different situations and the capabilities of the different tools.