The 2012 edition of the Open Source Convention (OSCON) is under way this week in Portland, Oregon, US. This means that what used to be called OSCON/Java is now also under way. I think it's a good thing that Java and the JVM are no longer a somewhat separate "mini-conference" within OSCON, but instead they're now a "track" within the mainstream conference. The former separation of Java (and also "OSCON/Data") from the main conference implied that these were "candidate" or "emerging" open source realms. But, as Java.net (2,109 active projects as I write this) and many other Java open source project host/repositories illustrate: Java is indeed mainstream with respect to open source. So, I'm pleased to see this change, making Java and the JVM simply a track within the general OSCON conference. The Java.net community is present at OSCON, and actively documenting their experiences for us. Java.net Community Manager Sonya Barry arrived in Portland on Friday afternoon. In her OSCON 2012 kicks off today! post, she tells us that she attended the Community Leadership Summit on Saturday, and she was going to attend the Ignite talks Monday evening. Java.net blogger Harold Carr is also at OSCON this year. Harold does an excellent job of documenting the sessions he attends for those of us who weren't able to attend. Thus far, he's documented OSCON Monday July 16, 2012 (which featured sessions on building apps with MongoDB, getting started with open stack, and Scala koans), and OSCON Tuesday July 17, 2012 (which featured sessions on CSS, building social and personal data apps using the Singly platform, a visit to the OSCON Exhibit Hall, and a party at Puppet Labs). Sonya also reported on her Tuesday at OSCON: Tuesday morning I got up bright and early to attend Steve Chin's JavaFX 2.0 tutorial. I've known Steve for several years now, but this is the first time I've sat down in a tutorial/hands-on-lab kind of environment with him to work through a problem. I had a great time, and I learned a lot about the new features of JavaFX... Tuesday evening we packed up our business cards, stickers, and screen cleaners and headed out to the Expo reception. We spent an hour hanging out in the Oracle booth with a bunch of folks from MySQL, and Oracle Technology Network. I also had a chance to wander around and saw one of the most exciting new things this year - Greenlight for Girls! This week they are doing a "mission to Mars" project with thirty girls age 11 to 15 in the expo hall. On the first day they'll build the mars-scape, and the next day they'll program robots to navigate the terrain. I'm looking forward to watching that come together over the next couple of days. OSCON is indeed a great convention. I attended it once, and I hope to attend it again -- like, maybe every year going forward! I wish I was there this year, but I'm not (such things happen in life!). Since I'm not there, I'm very grateful to both Harold and Sonya for taking the time and effort in this tweet-dominated world, and after a long day of conference attendance, to write actual paragraphs that describe their OSCON experiences in ways that permit us to genuinely feel something of what it's like to be at OSCON 2012! Java.net Weblogs Since my last blog post, several people have posted new java.net blogs: Sonya Barry, OSCON 2012 kicks off today!; Larry Fernandez, Wiring Java Objects Together - the Object Model; Harold Carr, OSCON 2012 in Portland, Oregon; Harold Carr, My OSCON 2012 Monday; Harold Carr, My OSCON 2012 Tuesday; and Sonya Barry, Tuesday at OSCON. Java News Here are the stories we've recently featured in our Java news section: Paul Sandoz illustrates Java 8, Lambda and method references; Markus Eisele explains GlassFish Operations: Log Notifications; John Clingan announces GlassFish Server 3.1.2.2 Now Available; Micha Kops details Aspects of Functional Programming in Java; Dalibor Topic shares JavaOne 2012: OpenJDK Edition; Geertjan Wielenga presents a More Serious Attempt at a NetBeans Gradle Plugin; Christian presents Understanding the concept behind ThreadLocal; Terrence Barr notes there's So much happening in JavaFX; Geertjan Wielenga provides Notes on Gradle and NetBeans; Spotlights Our latest Java.net Spotlight is Mark Reinhold's There's not a moment to lose!: The aim of Project Jigsaw is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK. Jigsaw is currently slated for Java 8. The proposed development schedule for Java 8 expects work on major features to be finished by May 2013, in preparation for a final release around September. Steady progress is being made, but... Articles Our latest Java.net article is Ken Rimple's Spring Roo and WebFlow. The article is the first in a series that will explore how Spring Roo integrates (and doesn't) with various technologies. This first article discusses Roo and Spring Web Flow. Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of Java.net in the java.net home page archive. -- Kevin Farnham Twitter: @kevin_farnham AttachmentSize OSCON2012.png18.06 KB

Welcome to the mind of David Eaves (@daeaves), public policy entrepreneur, open government activist and negotiation expert. Speaking in a rapid fire style, Dave admitted to "dumping" hours of negotiation theory in a few minutes in his OSCON session "Open Source 2.0: The Science of Community Management." I, for one, was delighted to be soaked by the firehose. Dave started by debunking the 3 Great Myths of Open Source communities: Myth 1) Your Open Source Community is a Meritocracy. Admit it, the first 10 people to join your project have much more power than the next 10 that join, even the next 100. The first UI person to the project will be "the UI guy," it will take a serious stumble by him or a person drastically better then him to be displaced. The meritocracy myth is particularly harmful because it creates the promise that if you work really, really hard, you will have the same opportunities as everyone else in the community. Because of human nature, that's just not true. People are generally creatures of habit and go to the people they already know. It takes real effort to expand the circle/change their ways. For more information, you can read Structurelessness, feminism and open: what open advocates can learn from second wave feminists (this is in part about why open source communities are not pure meritocracies). Myth 2) Open Source is about Collaboration The genius of open source is how *not* to work together. It's about taking complex problems, breaking them into chunks and that individual developers can go work on and then can slide back into the whole. Collaboration is slow, expensive and high touch, community leaders should always think of ways to move from collaboration to cooperation. For example, it used to require long negotiations with the owners of the trunk to get extensions into Firefox (collaboration). With Firefox addons, community members could add functionality and users could pick it up much more easily (cooperation). Myth 3) Coders Don't Need Soft Skills If the success of your open source project is attracting (and keeping) community members, then your soft skills are your differentiator, not your coding chops. Be aware of the assumptions you bring to every conversation (Is this a negotiation? What's my goal? Is my goal just to prove the other guy wrong?). Your mindset can be resources are scarce, this is a battle, and eveyone else is stupid, crazy and evil. Or, you can believe that the pie can be made bigger, this is cooperative venture and people do what they believe is in their best interest. As a community leader, you can set the tone and maximize the outcome. Your job is not only to listen to what someone is saying, but to find out what are their real interests and concerns. A good solution may be closer than you think. Architect in Cooperation How can the OS community build "cooperation" into tools? Dave gave a few simple examples that would make Bugzilla more friendly: Making Bugzilla a Little Friendlier marking a user a new or that English is their second language (ESL) [think before you flame] sample text in a fields that models "right behavior" providing a "Why?" field (getting to the underlying need). creating a "support" state (which automatically generates an email that has links to similar entries in the support database rather than only giving a user-hostile reply of "invalid). Tools are especially challenging area for the open source community, but it is time to start asking for (or building) ways to minimize the high 'transaction costs' it takes to work your project. There's lots of work to do, but knowing you have a problem is always the first step. :-) For more information, Dave provided links to Posts on Open Source Community Management. There's also a nice set of notes on the session by Jeff Longland.

Roundup '12 - (Variations in) Pair Programming (Variations) Pair Programming is hard, because it’s social. In this session hosted by Dianne Marsh and Andrew Harmel-Law we discuss different approaches to adopting this agile practice. Thanks to Todd Costella, Jack Leow, Eirik Bjørsnøs, Chris Marks, D.J. Hagberg, Brian Gray and Victoria Vickers for their valuable input.Recorded at the Java Posse Roundup 2012 in Crested Butte, COThanks to Andrew Harmel-Law for production help. A Pair Programming Tarot The Pair Programming Rules (from extremeprogramming.org) The Pair Programming Idioms (from extremeprogramming.org) A Pair Programming Tarot Lightning Talk (youtube) A Pair Programming Tarot Slides (slideshare) “Two Brains and Two Sets of Hands” Pair programming with personal input devices, but shared and mirrored screens Adoption Developer led versus “militant” “all-pair-programming-all-the-time” In our experience its not always appropriate to use it The Importance of the physical space The desk and chair layout The problem with “the rest of your job” How do you fit in other, non-pair tasks like email, calls, lunch, etc? Pair Programming Remotely ON PURPOSE Google Hangouts Plus “your own space” Good relationships make this a minor / non-existent barrier to success Not every day, also work co-located regularly The “@Debt thing” example The @Debt project Wiki and Code (Kenai) Windows Livemeeting Importance of good relationships And importance of ability to think out loud Impact on Planning Plan in pairing at estimation stage “2x2” - 2 people for 2 hours Record the time for both people for the whole time Problem: How to handle it if not planned in - do we both record time against the task? Option 1: stop estimating at Task / hour level Just focus on Story Points / Sprint for your team You can still break a Story into Tasks to visualise your work and allocate it, but don’t estimate them This is slightly “black box” Sprint-level progress reporting Pairs of different skill levels It works best with people of similar skill levels But this is not the only way Benefits of onboarding and knowledge sharing But you can’t tolerate egos Which you are more likely to see in the expert Remember this skills transfer ought also to include the skills of pairing itself Mindfull Programming Being aware of yourself as you program And also being aware of the other half of your pair as you program Teach without making the other half feel they are stupid How to pair up? What if you have odd numbers of people? Rotate pairs every day Culture of “you must pair with everyone else within a Sprint” Just let them decide themselves On a task-by-task basis On an ad-hoc basis Sitting next to someone while they program is not pair programming Letting go of Driver / Navigator When you’re really flowing as a pair, you’re both Driving and both Navigating You’re really collaborating How to get there? Use the Ping Pong Idiom: One person writes a test, the other person implements it Break through egos by writing a test which breaks the thing just written Liked this on Code Retreat But what if the skill gap is too large? Don’t be dogmatic If it’s not working, just STOP Pair Programming in Interviews Chance to reduce stress of interviewee at every opportunity Adoption Techniques (when none of you are experienced Pair Programmers) Deliberate practice Workshop with tasks (the TDD Katas are good for this) A few lightning talks before (about pairing approaches) Experiment and mix the pairs Reduce the amount of “reality” Corey Haines Code Retreat - Jim Hurne gives a lightning talk about Code Retreats at JPR2011 Challenging the assumptions of “different skill levels” This introduces the ego right there Instead value the spectrum of skills that each person comes from John the UI Guy’s website: www.ilikepixels.co.uk Managing the bits in between the pair programming sessions I.e. synching the non-programming schedules of the pair Nothing in the available literature seems to talk about this But how do you manage it? One of the pair is almost always having to think about personal life stuff they need to do Explicitly schedule it it And also don’t pair all time - it’s HARD WORK Difference from working individually Individually you can turn lots of your brain off - e.g. the social bit But in Pair Programming this is very much on WHich is draining But it can also be addictive Certified Scrum Developer www.scrumalliance.org/pages/certified_scrum_developer Ron Jeffries Chet Hendricksen Pairing with non-Programmers Business experts Testers Operations Non-Verbal Cues Pairing when one person is standing and the other sitting Body language has a role to play Home field advantage - always pairing at one half of the pair’s desk Pairing Stations Gets round the problem of using some else’s setup Different IDE setup Different keyboard Mac / Windows Don’t make me think International Pairing The problems of Finnish keyboard mappings Sharing code with a DVCS (like git) to get round the someone else’s setup problem “Push” and share the code when you swap Makes you think in logical pieces of work Frequency of Control Switching “It depends” “Trio Programming” One coding, two writing tests Everyone has a different views of the world Advantage of cycling pairs - everyone knows all the code And more than the code; involve the DBA too Disadvantage of cycling pairs - context switching to begin with this is the case but then you got a better view of the codebase the code looked like a team had written it The positive social pressure of pairing Builds better code Counters the risk of over-engineering The angel on your shoulder N.b. it can go the other way - but most folks are aware of our own failings Lack of Resources pairwith.us (not “pairwith.me” as mentioned) How much Pairing? You can burn out It can be relentless when you’re learning it It challenges a lot of your introversion Take small bites Find the pair tasks Breaking down tasks At Sprint planning It’s an art Keep breaking things down Waiting until the “last responsible moment” Remember it’s about finding the sweet spot for your team - it’s the variations Team dynamic specific Project specific Company culture specific It depends A culture of self-organising teams will avoid lots of the potential problems you might find in adoption Test Driven Development Red / Green / Refactor - it is a very deliberate process Test Driven Development: By Example (Kent Beck) - Amazon Remember the “D” stands for “Driven” - designing the API at the lowest level There is a lot of emotional language in the book The “smallest possible increment” adoption method Martin Fowler’s Afterword to “TDD: By Example” - Google Books TDD as if you meant it - http://www.infoq.com/presentations/TDD-as-if-You-Meant-It Stop and think about it Are you in the proper state of mind to be developing? - E.g. are you too tired? Check by writing tests Thanks Libsyn.com - http://www.libsyn.com - for hosting and bandwidth Feedburner.com - http://www.feedburner.com - for feed redirect Kirsty Doherty, Amy Ehmann for Java Posse artwork Theme Music: Opening - "Java" the parody song Copyright 1997 Broken Records and Marjorie Music Publ. (BMI), written and performed by Loose Bruce Kerr of the Dr. Demento Show and Sun Microsystems attorney. Based on the WWI popular song, "Ja-da." Ukelele style on the recording taught to Bruce by his dad. Re-produced with kind permission from "Loose" Bruce Kerr - http://loosebrucekerr.libsyn.com http://www.youtube.com/watch?v=TAX0gJt-aZg Closing - Juan Carlos Jimenez - In the House (Intro No. 1) To contact us: Visit our homepage - http://javaposse.com Post on our Google Group - http://groups.google.com/group/javaposse Pose a question on our Google Moderator group - http://tinyurl.com/q4javaposse Call us with questions and feedback - (408) 465-4626 Or send us email - javaposse@gmail.com The Java Posse consists of Tor Norbye, Carl Quinn, Joe Nuxoll and Dick Wall

We are pleased to announce that the full SDK for Android 4.1 is now available to developers and can be downloaded through your SDK Manager. You can now develop and publish applications against API level 16 using new Jelly Bean APIs. We are also releasing SDK Tools revision 20.0.1 and NDK revision 8b containing bug fixes only. For many people, their first taste of Jelly Bean will be on the beautiful Nexus 7. While most applications will run just fine on Nexus 7, who wants their app to be just fine? Here are some tips for optimizing your application to make the most of this device. Screen Giving Nexus 7 its name, is the glorious 7" screen. As developers we see this as around 600 * 960 density independent pixels and a density of tvdpi. As Dianne Hackborn has elaborated, this density might be a surprise to you but don't panic! We actively discourage you from rushing out and creating new assets at this density; Android will scale your existing assets for you. In fact the entire Jelly Bean OS contains only a single tvdpi asset, the remainder are scaled down from hdpi assets. To be sure the system can successfully scale your hdpi assets for tvdpi, take special care that your 9-patch images are created correctly so that they can be scaled down effectively: Make sure that any stretchable regions are at least 2x2 pixels in size, else they risk disappearing when scaled down. Give one pixel of extra safe space in the graphics before and after stretchable regions else interpolation during scaling may cause the color at the boundaries to change. The 7" form factor gives you more space to present your content. You can use the sw600dp resource qualifier to provide alternative layouts for this size screen. For example your application may contain a layout for your launch activity:res/layout/activity_home.xmlTo take advantage of the extra space on the 7" screen you might provide an alternative layout: res/layout-sw600dp/activity_home.xmlThe sw600dp qualifier declares that these resources are for devices that have a screen with at least 600dp available on its smallest side. Furthermore you might even provide a different layout for 10" tablets: res/layout-sw720dp/activity_home.xmlThis technique allows a single application to use defined switching points to respond to a device's configuration and present an optimized layout of your content. Similarly if you find that your phone layout works well on a 7" screen but requires slightly larger font or image sizes then you can use a single layout but specify alternative sizes in dimensions files. For example res/values/dimens.xml may contain a font size dimension: <dimen name="text_size">18sp</dimen>but you can specify an alternative text size for 7" tablets in res/values-sw600dp/dimens.xml: <dimen name="text_size">32sp</dimen>Hardware Nexus 7 has different hardware features from most phones: No telephony A single front facing camera (apps requiring the android.hardware.camera feature will not be available on Nexus 7) Be aware of which system features that you declare (or imply) are required to run your application or the Play Store will not make your application available to Nexus 7 users. Always declare hardware features that aren't critical to your app as required="false" then detect at runtime if the feature is present and progressively enhance functionality. For example if your app can use the camera but it isn't essential to its operation, you would declare it with:<uses-feature android:name="android.hardware.camera" android:required="false"/>For more details follow Reto Meier's Five Steps to Hardware Happiness.Conclusion Nexus 7 ships with Jelly Bean and its updated suite of system apps are built to take advantage of new Jelly Bean APIs. These apps are the standard against which your application will be judged - make sure that you're keeping up! If your application shows notifications then consider utilizing the new richer notification styles. If you are displaying immersive content then control the appearance of the system UI. If you are still using the options menu then move to the Action Bar pattern.A lot of work has gone into making Jelly Bean buttery smooth; make sure your app is as well. If you haven't yet opted in to hardware accelerated rendering then now is the time to implement and test this.For more information on Android 4.1 visit the Android Developers site or join us Live. Join the discussion on +Android Developers

Dear Spring Community, I am pleased to announce the first milestone release of Spring Shell project! Spring Shell is an interactive shell that can be easily extended with commands using a Spring based programming model, extracted from the Spring Roo project. Downloads | JavaDocs | Reference Documentation | Changelog For more information about Spring Shell please see the home page. We look forward to your feedback on the forum or in the issue tracker.

We introduced a set of EC2 instance status checks at the beginning of the year. These status checks are the results of automated tests performed by EC2 on every running instance that detect hardware and software issues. As described in...

eBay's X.commerce platform is trying to change the way developers build and sell ecommerce apps.

Atulya Beheray of the AWS Messaging Team has written a guest post to introduce a new paper that his team has put together to show you how to use the Simple Queue Service in highly scalable fashion. -- Jeff; Amazon...

In this article I will provide you an effective and optimized approach of Factory Design Pattern in Java. As you know theFactory Method Pattern or popularly known as the Factory Design Pattern is one the design patterns under the category of "Creational Design Pattern". The basic principle behind the pattern is that at run time we get an object of similar type based upon the parameter we pass. There are many articles on this pattern and developers implement in various ways to achieve it. In this article I will show you how to create a better and most effective way of designing factory design pattern.

This article gives you an inner insight into the design of a better singleton design pattern. In this article you will be able to learn how break a singleton design if it not designed properly. It will help you to follow the best practices adopted in the industry. A few days ago when I was in my home town, one of my sub-juniors from my colleague attended an interview in an MNC and was severely injured in that interview process. I mean he could not qualify the interview because of the difficult questions fired by the interview panel. When I came back to Bangalore, he sharedthe embarrassing situation he confronted during the technical interview. Based upon his experience today I am writing this article on the Singleton Design Pattern. By the way my junior colleague has nearly four years of experience in Java. One of the controversial questions he faced was "What is the Singleton Design Pattern and how will you write a robust singleton class? " However let me give you the basic and critical outlines of the Singleton Design Pattern frequently used at the time of project/product development.

Micah Martin discusses creating web applications with Clojure and Joodo and Gaeshi deploying them on Google App Engine and Heroku. By Micah Martin

Hamburg company, Froglogic have been swift to make their GUI testing tool Juno-compatible, announcing support for automated testing of Java (RCP) applications that are based on the latest Eclipse release. Claiming to be the leading 'functional, cross-platform GUI and regression testing tool, Squish is ideal for running automated GUI tests for Java SWT/RCP and AWT/Swing applications. The move to support Eclipse 3.8 and 4.2 RCP applications is a logical one, with advances in RCP technology seemingly occuring daily now. Making sure that the large amount Eclipse developers are able to get Squish working the best for them should be of paramount importance. One of Squish's main advantages over competitors is its ubiquity, with it and its test being able to work on Windows, Linux/Unix, Mac OS X. That's without touching the numerous mobile and embedded platforms that you can test applications on: these include Nokia's Qt, HTML and AJAX, Java SWT, Mac OS X Carbon and Cocoa, .NET and iOS CocoaTouch. With the converging nature of software development at the moment, having this plethora of platforms.  Its flexibility should be noted too - offering several scripting languages such as Python, JavaScript, Perl, Ruby, as well as Java of course. The Squish Automtion Suite is essentially split into three entities: the core Squish for GUI testing, Squish Central for test automation management and Squish Coco for code coverage. Across the board, expect ample opportunity to integrate several tools into the mix, a powerful Eclipse-based IDE and several add-ons. Froglogic CTO, Harri Porten spoke of the release: Our customer base who is automating GUI tests for Eclipse based applications with Squish continues to grow significantly. We expect many of them to update their applications to the new Eclipse version soon. Therefor it is very important for us to keep Squish's RCP/SWT testing support up-to-date with new releases of Eclipse – while also keeping support for older versions current. With some substantial users already onboard, such as Google, Airbus, Boeing and Vodafone, Froglogic's Squish appears to be the enterprise market leader for automated testing for being so comprehensive, and doesn't look like it'll be giving up that accolade any time soon.

"Pragmatic Continuous Delivery with Jenkins, Nexus and LiveRebel" is a practical guide that harnesses the theory of Continuous Delivery for implementing an automated, trackable production delivery pipeline using commercial and open source tools available right now.

After successfully deploying their Affiliate Membership programme, which attained some pretty poweful allies, the Open Source Initiative (OSI) has sounded the call for individual members to join the organisation and support its open source-advocating goals. The timing couldn't have been much better, coinciding with OSCON - the biggest open source gathering going. The non-profit organisation is now accepting applications for Individual Membership, where individuals will become involved in OSI governance. Applicants are encouraged to make a tax-deductible donation of $40 (where possible, accrued annually). The move is another step in the OSI's radical restructuring process, shifting towards a completely member-driven structure, moving away from the model where self-appointed directors were present. After 14 years with this outdate model, the board decided to open up the OSI more - to allow developers, users and vendors a more direct role in its advocacy. At the helm of this overhaul is OSI president Simon Phipps, appointed this year to oversee the big move - an ideal candidate given his passion for preaching the open source state of mind. His first proposal was to open the Affiliate Membership program, inviting not-for-profit organisations into the fold. Currently, 22 members are on the books - from Apache to Wikimedia, and just recently, three more Affiliates have joined. These include the Open Source Software Institute, the Python Software Foundation, and the Brazilian Java user group Soujava. The latter is especially encouraging to hear, with one of the most proactive and biggest community groups around getting onboard. Phipps said: "The transformation of the OSI into a member-based organization is a timely and important step for the worldwide open source community". The new Individual Membership category allows individuals to support the mission and work of the OSI by joining discussions about that work and help shape the future for the OSI itself. This isn't a mandatory requirement for Members however. It's well worth your while supporting a very important cause for software development, helping educate others on the merits of open source models. Due to economic embargoes, donations cannot be accepted from all countries. Check here for more details. Why not get involved!

Java Application Architecture: Modularity Patterns with Examples using OSGi is Kirk Knoernschild's semnial book on a pattern catalogue for modular systems design. Starting with an overview of the arguments for modularity, the main section in the book introduces eighteen categorised patterns for module development, and concludes with an OSGi example. InfoQ spoke to Kirk to find out more about it. By Alex Blewitt

Runar Bjarnason talks about the ideas behind and features in the popular scalaz library, programming concepts like (bi-directional) lenses, Scala Macros, and much more. By Runar Bjarnason

Oracle exec says Project Jigsaw technology has been deferred until 2015 with release of Java SE 9.

Mark Reinhold's announcement yesterday that Project Jigsaw, the eagerly-anticipated standard module system, would now be delayed until Java SE 9 in 2015. The proposal was met generally with ire, although some did come out in support of the decision. To recap, Reinhold, the Chief Architect of the Java Platfom Group at Oracle, gave the following reason for the deferral of Project Jigsaw: Steady progress is being made, but some significant technical challenges remain. There is, more importantly, not enough time left for the broad evaluation, review, and feedback which such a profound change to the Platform demands. I therefore propose to defer Project Jigsaw to the next release, Java 9. In order to increase the predictability of all future Java SE releases, I further propose to aim explicitly for a regular two-year release cycle going forward. Reinhold goes on further to explain why he opted to keep the two-year release cycle, in expense of arguably the biggest feature targetted for Java SE 8. It's a fine balance, keeping the enterprises happy with stability (with as short a release cycle as they can possibly accept) and the wider community hooked with innovation. The general consensus from the Java community however, has been one of disappointment, and it's fair to say some are quite angry at the further delay for a much-needed modularisation introduction to the language. Just by glancing at the comments on Reinhold's blog reveals how vehemently opposed some are, although it's about 50/50 for the decision. For example, Markus Karg wrote the following: In fact it is a bit ridiculous that Jigsaw is stripped from JDK 8 as it was already stripped from JDK 7. What will be next? Moving it to 10 after 9, 11 after 10? Just give up the idea and use Maven. It's here already and serves well. Also the time frames are rather fantastic. A two year release seen as a big improvement? Maybe when thinking in astronomic dimensions. Why not following the release often approach, having one release each Summer? The 'just use Maven' brigade are certainly there (with equal discontent shown towards them too), whilst many advocate the use of OSGi in the long-run. Although Oracle seem resistant to that. We understand the decision to let the train leave the platform, but what is the point if the train has no cargo, as Jim DeVos commented. This puts a lot of pressure on Lambdas and the Date/Time API as part of the Java SE 8 release, but is it really enticing to enterprises to pick up Java SE 8 when it now looks devoid of a major component as promised? Are they enough to suggest Java is heading the right way, continually innovating? Whilst it should now ship on time, the minor-major cycle has certainly been disrupted. Interestingly, Groovy Project Lead Guillaume LaForge gave his two cents, explaining how Groovy went about the modularity problem: We didn't go too far with modularity in Groovy 2... because we didn't want to duplicate what was supposed to be coming in Java 8.  But now, it means it won't be in the hands of developers before 2 years, and in production before 3 years :-( It means that Jigsaw, if it ever ships, will have been 5+ years in the making. That sounds a lot, even for such a big feature and task. An excellent point made - whilst Project Jigsaw is clearly a huge undertaking, that amount of time doesn't really add. Will Project Jigsaw ever see the light of day? The pace we're going at the moment seems to suggest that we may not.  So where does this leave Java now - a bloated mess of a language? Will it be left in the dust of other JVM languages that display some semblance of modularity already, like Scala and Groovy. There was no easy decision to be made here, with people bound to be upset by it, but we want to know your views on this - was it right to defer Jigsaw? Comment and vote below... Java 8 without a module system - what's your view It was the right decision if it wasn't ready for Java 8 No Jigsaw is annoying, but time should be taken on it Other options should have been considered instead of Jigsaw being missing Jigsaw should have been pursued - some module system is better than none Java 8 is no longer a big release - Java needs a module system badly Created on Jul 18, 2012 View Results poll by twiigs.com

I started to fill out a table of all of the Java Specification Requests that are supposed to go into Java EE 7. Because the platform edition is still being decided, some of the details are rather hard to pin down. The full EJB Product for Java EE 7 has these following standard components and APIs:- Preview Text: I started to fill out a table of...

Been a while since I did this; turns out it's easy enough. First, you'll need the current JDBC driver from Microsoft, which can be found here. Add to classpath as usual. Set up your Java application to use the following JDBC connection settings: Preview Text: Been a while since I did this; turns out it's easy enough. First, you'll need...

I believe most of the Java Developers are aware of the latest Java release i.e Java 7. Preview Text: I believe most of the Java Developers are aware of the latest Java release i.e Java 7. A lot of us are disappointed about quite a few important features being deferred to Java 8, but its really good to see the language evolving and lot of things...

In his post Project Jigsaw: Late for the train, Mark Reinhold's proposes "to defer Project Jigsaw to the next release, Java 9." He explains the reasoning for this: "some significant technical challenges remain" and there is "not enough time left for the broad evaluation, review, and feedback which such a profound change to the Platform demands.&quot ...