I recently sat and passed the Sun Certified Java Programmer 1.6 exam (310-065). Throughout my life I have found exams unusually difficult so I wanted to share some tips which I found invaluable in case they are of help to others.

The exam:

Before explaining my revision tactics it might be useful to give a bit of background on the exam itself. The exam is a multiple choice test which consists of 60 questions, has a pass mark of 58% and a duration of 180 minutes. This gives approximately 3 minutes to answer each question. Questions with more than one correct answer will state how many answers should be picked, but exactly the right answers must be selected for each question to get the mark. Most of the questions involve reading a code excerpt and detailing the outcome of the execution of the code, some questions involve dragging code snippits in to the appropriate place in a code excerpt. The exam is not negatively marked.

So without further ado, here are my revision tactics:

• Read the official book(s) - There are several books on the market which exist specifically to teach the exam subject content, reading at least one of these in detail is one of the most important things you can do. I chose the study guide by Kath Sierra and Bert Bates and found it to be excellent; the book covers all the official certification objectives in detail and also provides a useful section on how to prepare for the exam. As an added bonus the book comes with a free CD which contains the book content as a PDF plus an exam simulator containing 2 full length mock exams. Note that there are many other SCJP 1.6 books available which are definitely worth checking out before you decide which to buy as you never know which will suit you most.
• Learn the chapters and objectives - The SCJP exam will only test you on the official objectives, the exam questions are notorious for being deliberately ambiguous about what they are testing (by including red herrings) and for often referencing at least one objective even when the answer refers only to a sigle objective. Thus knowing the objectives can give you a distinct advantage in helping to quickly identify what a question is really testing you on, it also makes it quickly to spot and eliminate red herrings allowing you to answer questions more accurately.
  
• Do mock exams - Mock exams are important since they allow you to test your skills, identify strong/weak areas and determine your question answering speed. Having worried that I would run out of time in the real exam I found this really beneficial as I determined early on that I generally took about 90 seconds to answer each question. This was comforting to know and made me much more relaxed in the real exam as I knew I would have time to complete all questions and review my marked questions. There are several sites which offer free mock exams, I used www.certpal.com which contains full mock exams for both the SCJP 1.5 and 1.6 certifications. Don't be put off by the slightly basic design of the site, or by the occasionally badly worded question explanations as the quality of the questions outweighs both these things. With retrospect, having now taken the exam, I can see that the certpal questions were consistently harder than the real exam questions, so if you can consistently get a good pass mark on certpal that's a good indicator of being ready for the exam. However if you don't like certpal then JavaRanch maintain a useful list of SCJP mock tests.
  
• Code! - Seems obvious doesn't it but you'd be suprised how many people apparently don't sit down and learn through coding. I found that writing small pieces of code, specifically targeted in testing an individual objective or API, to be hugely beneficial in enhancing my understanding of my weaker areas. Coding also helped me  in learning a new objective/API that I hadn't previously used much before (java.util.NavigableSet and java.util.Scanner were pretty new to me). I also found coding really useful in a couple of instances where I didn't understand the answers to certain mock exam questions, being able to code the question and then debug through the code line by line caused me to unlearn a couple of my own mis-understandings which would have otherwise tripped me up in the exam.
  
• Use forums - Again when reviewing my mock exam question failures there were a few instances when, even after coding and debugging a question, I failed to understand WHY the JVM would demonstrate a certain behaviour. I found JavaRanch to be an invaluable resource here, particularly the Big Moose Saloon forums which have friendly and dedicated boards for SCJP questions and answers.
  
• Make revision a regular practise - Revise regularly and often, in a consistent manner each time. I gave myself 8 weeks to revise for the exam and changed my daily routine by doing the following:
  • I stopped cycling to work and instead took the train.
  • Each morning and evening on the train I revised by reading new material or re-covering old material or by reading flashcards
  • During lunch each day I took 15-30 minutes to make detailed revision notes on what I had read that morning.
  • Each evening I varied my revision by either coding, condensing my detailed notes to concise revision flashcards or doing mock questions (not whole exams though).
  • On each of the last 3 weekends I sat a full length mock exam and went through my question failures and flash cards.
• The above is what worked for me and what suits each person is going to be highly subjective. My point here is that you should try and find something that works for you, whatever that may be.
• Make flash cards - Flash cards are a brilliant and very portable means of concisely documenting  information. Keep them brief, use bullet points and mnemonics where possible, carry them with you and test yourself (or get others to test you) as often as possible.
  

I think that's about it, ultimately the SCJP does take a small chunk of time out of your life so it's worth making sure you can dedicate that time before you commit to booking the exam. However I think it's a useful certification to have and as someone who has been developing Java for several years I am pleased that taught me some new things that I didn't know and helped me un-learn a couple of things I thought I knew! Hopefully this will serve to make me a better software engineer!

I hope this is helpful to anyone considering/ already studying for the SCJP exam - good luck!

Cheers,

EdD.

It may be the case that I'm not looking hard enough but I can't find this anywhere in the documentation:

To achieve a cascade type of 'none' using Hibernate annotations you'll need to do the following:

@OneToMany(cascade = {})

Exactly why they couldn't have provided CascadeType.NONE enum I don't know.

EdD

Just a quick post to say that the London Java Community (LJC) now has its own website. Barry Cranford has set the site up to publicise the group, which is rapidly growing in size, and its activities and events. Barry has done a great job with the community so far and continues to provide great events for Java technologists.

If you're interested in the LJC's activities or want to get involved you can find the site at http://www.londonjavacommunity.co.uk.

Cheers,

EdD

• In the 'Project Explorer' view select a folder that you wish to exclude from search results.
• Right click the folder and select 'properties'.
• Select the 'Derived' checkbox.
• Click 'OK'.
  

Last night I attended the 'Android for Java Developers' event which was put on by the London Java Community. Reto Meier, an Android advocate from Google took us through the basics of the platform and covered topics including IDE support, some of the libraries available, how applications are assembled and signed and also provided some information on the Dalvik virtual machine.

A couple of Android devices were passed around for us to play with during the talk, having never used Android before I had somehow arrived at the conclusion that the OS was a bit clunky compared to the iPhone/ Palm Pre, this illusion was quickly dispatched when I got to play with the devices and I was in-fact impressed at how responsive and feature laden both devices were. (Note to self I will definitely be getting an Android phone as soon as the contract on my horriffic self rebooting N95 runs out!)

The event was really interesting, as a developer it was pitched at just the right level giving an insight in to both technical and commercial aspects of the platform and also providing useful feature comparisons with other platforms. I was also pleased to hear about the inclusion of proper threading support: Android/ Dalvik has a multi-threading model analogous on a basic level to standard Java whereas the iPhone OS is inherently single threaded. I see this as a serious plus point for Android since phone apps are already getting more complex and often need to be able to run as background services without locking the rest of the phone up.

So there you have it, many thanks to the LJC for putting on the event, Google for hosting us and to Reto and his colleague (whose name I have forgotten - sorry!) for an entertaining and enlightening talk! I'm now off to write a best selling Android app, make my millions and retire early!

EdD

The ECMT manager which forms part of the S60 MIDP SDK doesn't work out of the box with Java 1.6 (6.0). In this situation the error 'Cannot start ECMT Manager' is displayed when attempting to open the manager.

To fix this do the following:

•  Navigate to <S60 MIDP SDK Install Path>\bin\epoc32\tools\ecmt\config
• Backup (via copy) config.properties to config.properties.original
  
• Open config.properties in a text editor
• Locate the property epdt.java.version.start and append the String ',1.6,6.0' (excluding the quotes) to it's value
  e.g. epdt.java.version.start=1.4.1,1.4.2,1.5,5.0,1.6,6.0
• Save the file.

Now try and open the ECMT manager again, if the fix has worked then the manager should open without any errors occuring.

Hope that helps,

EdD

I have found this quite useful, it lists a load of useful Maven properties which aren't obviously available in the Maven documentation:

http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide

EdD

I recently started using Hudson as a Windows service, upon doing this I noticed that it completely ignores my Maven configuration file %HOMEPATH%\.m2\settings.xml. I couldn't initially figure out why this was happening until I remembered that Windows services run by default as the system account, not as a user account.  The system account doesn't have any concept of the same %HOMEPATH% environment variable which is used when I use Maven interactively which is why my settings.xml was being ignored under Hudson .

To overcome this problem make sure you use the settings.xml file under belonging to the actual Maven installation which Hudson uses to build your project, in my case this was:

 C:\Program_Files\Programming\Java\apache-maven-2.0.10\conf\settings.xml

A quick update to this file, adding in the settings I usually use (basically a Nexus mirror) sorted this right out.

Note: This should be obvious but by modifying the settings.xml belonging to the Maven installation you are essentially changing the system wide Maven defaults which will affect all users unless they have specified otherwise in their own settings.xml file.

EdD

IntelliJ has a wonderful feature which, during debugging, allows for the evaluation of code at runtime, this is one of my favourite debugging utilities and is accessed through ALT+F8.

I've been using Netbeans more and more recently and could not for the life of me figure out if there was an equivalent function... well there is, and it's CTRL + F9 which gives you this little wonder.

Once the window above appears you can just type in your expression (using CTRL + SPACE for code suggestion/ completion) and hit enter to see the results! I'm so pleased I've discovered this, I knew it had to be in there somewhere in NetBeans - it's just a shame it took me this long to find it!

EdD

It takes ages to re-install SJSAS so this should save some time when you need to test different appserver versions with different JDKs and don't have the time to reinstall or the resources to have multiple installs.

1. Stop your appserver domain(s), nodeagent(s) and instance(s).
2. Locate <SJSAS_HOME>\config\asenv.bat where SJSAS_HOME is yous SJSAS install dir e.g. C:\Sun\ApplicationServer.
3. Take a backup of the file.
4. Locate the 'AS_JAVA' variable. e.g. set AS_JAVA=C:/PROGRA~2/PROGRA~1/Java/JDK15~1.0_1
   
5. Figure out the DOS 8.1 path to the JDK you want to use and replace the existing path with this value.
6. Start up your application server.
7. Check the server.log output - it should contain the updated JDK path.

EdD

When you create an SJSAS Instance debugging is disabled by default, if like me you are often rebuilding your appserver and use appserver debugging a lot then this can become a real pain since an instance restart is required after every rebuild in order to switch debugging on. I recently discovered that you can programatically enable/ disable debugging which means that it is possible to switch debugging on in your appserver build script so that it is ready for you to connect as soon as you have built your appserver.

The ASADMIN command for this is as follows, you'll need to replace the bits in triangular braces with your own values e.g. <eddsBox> might become localhost. Note that this command doesn't alter the default port (9009) since I have encountered issues with SJSAS 8.1 when altering the port.

asadmin set --echo=true --host <eddsBox> --port <MydomainAdminPort> --passwordfile <path to pwd file>  --user <admin user> <instance-name>-config.java-config.debug-enabled=true

In my case this can be translated to the following Ant target:

<target name="enable-debug-on-instance" depends="-init"
    description="Enables debugging on the SJSAS instance - used for development purposes only.">
    <exec dir="${basedir}" executable="${asadmin-executable}" failonerror="true"
      failifexecutionfails="true">
      <arg value="set"/>
      <arg value="--echo=true"/>
      <arg value="--host"/>
      <arg value="${appserver-host}"/>
      <arg value="--port"/>
      <arg value="${appserver-domain-admin-port}"/>
      <arg value="--passwordfile"/>
      <arg value="${appserver-passwordfile}"/>
      <arg value="--user"/>
      <arg value="${appserver-admin-user}"/>
      <arg value="${appserver-instance}-config.java-config.debug-enabled=true"/>
    </exec>
  </target>

EdD

A few words after a remarkably quick and hassle free Roller installation...