![]() |
|
This page has 150 SCJP java questions. I am not quite sure whether they are for Java 1.4 or 1.5/5 SCJP exam but questions are questions and questions are good practise. The one critism is that the quesitons are spread out in 65 html pages and the question has the answer right below it so you sometimes see the answer before you have a guess at it but looking at this in a positive light at least by spreading out the questions you can tackle 2 questions a day (2 Q's on each page) and get into a good habit like that.
Whizlabs SCJP 5.0 Preparation Kit
I have been trying to do more question practice recently and put my SCJP Java 5 knowledge to the test (literally) I'm sure a lot of you who have searched for SCJP 5 resources would have come across the whizlabs. The free demo is a mixture of being useful but limited. You get 20 exam type questions with detailed answers (if you get them wrong) you also get 15 or so quiz questions which are mixture of true/false or typing in answers. For free y ou can't complain about the price or what you get. I don't know if I would want to be $60 for the full version although you get a 6 exams worth of questions. It would probably be worth it if there were a few of you doing it. The free demo is really good practice for the real exam because the questions are fairly tricky and I reckon they must be pretty close to the real thing. here's the link if you want to try it out http://www.whizlabs.com/scjp/scjp-5.0-details.htmlif anyone has any other good resources for the Java 5 SCJP exam please, please, please leave them in the comments and I will check them out
SCJP 5 Questions Questions Questions
This is my (current) tactic into getting myself match fit for the SCJP exam. Although reading articles, books and online stuff helps to learn the basic knowledge of Java, I have decided that to really get my knowledge up I am going to have to keep practicing questions. I think the problem with reading books/articles is that it's quite a passive way of learning and sometimes it's difficult to know if you are actually taking in the information. I have been doing my daily question as usual at at Marcus Green's excellent SCJP Mock exam question a day site http://www.examulator.com/phezam/question.phpit also has a link to a database of 60 Java 5 SCJP questions. I try to do the question of the day and then 10 more before starting work. If I get a question wrong then I note it down. I have found that doing questions helps you test your knowledge and reinforce it if you get it right and then if you get it wrong, you investigate why and are less likely to caught out again. Doing questions also helps you get up to speed with the typical exam tricks that you are going to be faced with. So recently I have been looking for some more questions to do and I found this site http://www.javareference.com/testcenter/It doesn't have that many questions but it's good practice until you have done them all. I have been working through the tricky tricky questions in my SCJP book, the questions are right swines and I am only getting about half right at the moment (ahhh 9 percent short of a pass!!!) but even though I have got only half of them right I think it is worth while doing the questions because it has highlighted some areas that I am not sure about. It has also hopefully picked up some areas where the exam is going to try and catch me out. If I take them again in a few days I will hopefully get more right because I will be watching out for certain tricks, although this isn't that a good test because I will have answered the questions before. I think the point I am trying to make is that by doing questions you are finding areas where you knowledge is lacking but how would you know this by just reading a chapter of a book or article etc. I have a link to 11 questions by Katherine Sierra and Bert Bates which I plan to tackle in the next day or so. http://hoskinator.blogspot.com/2006/05/11-scjp-java-questions-come-on-test.htmlIf anyone has any links to any automated SCJP 5 question websites then please leave them in the comments, it's much easier when you just have to tick a box etc rather than writing the answers on a piece of paper. Also Java Black belt is quite good for testing yourself, although some of the questions waiting to be verified can be of poor quality, overall it isn't bad http://www.javablackbelt.com/They have also recently added a Java 5 exam, which is pretty good.
Below are the links for documentation on Java 1.5/5 from sun. A good resource for people studying for the Java SCJP 5 exam or people who are interested to find out more about the new features in Java 1.5. They also offer a good place to have a quite look to see if there are any new features which you aren't using yet but could be useful.
this is the general entry page with links to many of the new features
http://java.sun.com/j2se/1.5.0/docs/index.html
This document is very useful because it talks about the new features and has links to tutorials, I highly recommend people study for the exam look at this page
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html
here is a link to API, if in the unlikely event you don't already use it
http://java.sun.com/j2se/1.5.0/docs/api/index.html
Concurrency Podcast
The current podcast from the Software Engineering Radio is about concurrency and Threads and is worth listening too. Here is a description of the episode
Java Tips
I stumbled upon this Java tips site yesterday and found some interesting tips, which were explained in great detail. So in the name of self improvement it’s worth checking out the Java Tips site.
I found a link to a Java 5 article resource at the IBM developer works website.
one article in particular I found useful, it gives a good overview of what you will be tested on the SCJP Java 5 exam
I'm sure a lot of people studying for the SCJP Java 5 exam will have been to the Java Ranch but in case you haven't I highly recommend you visit this page, it has links to loads of goods sites and also has lots of really useful information.
I really found useful and interesting because they are a collection of frequently asked questions on the SCJP
SCJP FAQ
Cracking the New Sun Certified Programmer for Java 1.5 Exam
I found a link to this presentation today by Khalid Azim Mughal. Cracking the New Sun Certified Programmer for Java 2 Platform 1.5 Exam It is an excellent resouce if you are thinking about taking the Java SCJP 5 exam or if you would like to know what is in the exam The article has interesting topics like Why you should get Certified "• Making career move from non-technical to application development.
• Criteria for promotion
• Validation of skills
• Improve Java skills
• Certified once, recognized everywhere" it also talks about how the exam is structured and the topics that are on the exam. It shows some example questions so you can gauge how difficult the exam will be. I found the article very useful so I thought I would share the knowledge and pass it on to any people studying for the SCJP Java 5 exam and are looking for some resources to help with the studying.
At last I have finished reading all 800 pages of the Sun Certified Programmer for Java 5: Study Guide Exam 310-055
I have finally finished reading the Sun Certified Programmer for Java 5: Study Guide Exam 310-055 (Certification Press S.)
I have reviewed this book but basically if you are going to take the Java 5 SCJP exam buy this book, end of story. Right as I was saying I had finally finished this beast of a book, yes 800 pages and many hours reading this big old text book whilst all my mates were out playing down the pub, ooohh what a cruel cruel world we live in. Still I am in good shape regarding the Java 5 SCJP exam, apart from the fact it has been so long since I started the book I can't remember the first five chapters and I feel that if I go back and read them I will stuck in a constant loop, like a dog chasing his tail. So now armed with my queue cards (spelling!!?!) I shall be reading and testing myself with those badboys. I will also be reading some final notes that I have a link to on my site (which means there are too many for me to link too). I shall also start doing some practise exams and just get up to stratch on exam questions and finding where my knowledge is weak. It is another step in the right direction, I feel now that my goal is in sight or I'm on the last few miles of a Marathon
Java Glossary
I found this really useful site from the Canadian Mind Products it has a Java Glossary. It has a Java section with useful sections like Java Cheat Sheet Java FAQ Java Gotcha's Scope of variables installing Java Generics Interface vs Abstract Jar JDBC Collections The site is well thought out with useful sections and useful in a practical way. I found the File section really useful and the Gotcha's was good. I have used this site a few times and came here a few times by just searching for things in google. I like the way it is split up into topics which make it very easy to navigate and also seem quite interesting.
It's a useful reference site
Excellent SCJP Study Resources and links
I found this link today and it is a really good SCJP Java 5 Study resource. It just has links to most of the areas that need to be studied for the exam. Here is the a link to the site. I would recommend visiting it because it also has other SCJP stuff like study notes and mock exams and some articles of it's own http://www.xyzws.com/scjp.do?cat=scjp&smenu=SGS12 Here are the links, it includes Generics, Varargs, enums. I think I have linked to most of these linked on my blog but not in one easy list. It's quite amusing I have read a lot of this links apart from the Wikipedia ones and the ones about garbarge collection infact. The Members' Collection of SCJP/SCJP(5.0) Resources that should help you guys out there
SCJP Revision Tips
I have been looking about on the web for any SCJP resources I haven't bumped into and I found this site which although based on an older SCJP exam it still had a couple of interesting pages. it had this page called SCJP Revision Tips http://www.tipsmart.com/studytools/revtips.htmSet is unique and do not allow duplicate objects to be stored. Elementsstored in
the Set are unordered and unsorted. HashSet class directlyimplements Set
interface try block without atleast one catch block or finally block after it givescompile
error.
Note that you can't create an array object with following declaration int
intArray[30]; They are things you should know but it's a good page to help you revise and go over things which might catch you out. The other page I found useful was called Study Tips http://www.tipsmart.com/studytools/studytips.htmit is just a list of some useful study tips and they are good common sense and practical tips. Actually there is another decent page the links page, this particular links page is full of links to mock exams, although as with many links on the net it is to an older exam, still practise is practise. http://www.tipsmart.com/studytools/certlinks.htmI hope people out there who are studying for the exam find these useful and if you have any good SCJP link please leave them in the comments and I will check them out.
Interfaces vs abstract classes
I recently read an article titled interface vs abstract class and imagined an Alien versus predator type block buster movie, introduced in a boxing Rocky style of course It is an interesting question, so I thought I would type it into google to see what else came up. I will assume the readers of this blog know the difference between interfaces and abstract classes but JavaRanch have this artice that states "1. You can implement multiple interfaces at the same time, but only extend one class
2. An abstract class is allowed to contain implementation (non-abstract methods, constructors, instance initializers and instance variables) and non-public members" Part of the argument regarding this question is also linked to theory that you should favour composition over inheritance. Abstract classes have to be extended which means they don't conform to a number of Object orientated rules which if you want to get a good grounding on it's worth reading Robert C. Martin articles on the subject, many of which can be found hereWhen I first starting to learn Java I really struggled to understand the use and idea behind interfaces they seemed very pointless to me. Abstract classes on the other hand were not so hard to understand (although not fully) because you can put some code in them. I think you start understanding the idea of both and then start to understanding when you should use one or the other is once you start thinking about the design of your code. I personally found this happened when reading the OO articles by Robert C. Martin and also seeing the good designs by reading a book on design patterns (head first design patters, very good). Once I saw that I could see the value of interfaces and abstract classes and the OO articles helped me to understand why the designs were good. Back to the discussion at a hand, this site provides a good introduction to Abstract class and Interfaces. The JavaRanch article has these points to decide whether to use Abstract class or an Interface "1. use an abstract class, if you want to provide common implementation to subclasses,
2. use an abstract class, if you want to declare non-public members,
3. use an interface if you want to provide the implementing classes the opportunity to inherit from other sources at the same time." I think the important point to consider when decided if you want to use an Abstract class is will it contain code that will be used by the subclasses (classes that extend the abstract class). Will the subclass be the same as the baseclass (superclass) but with extra methods and code or/and will they override some of the superclass methods. So if the classes that will implement an abstract class or interface will need to use the same code then I would say you want this code to be an abstract class. Be warned though you have to be cautious when deciding to use an Abstract class because it is then making the classes than extend it completely dependent on the abstract class. This can mean any changes you need to make to a core method can break all the classes that extend the Abstract class. On the other hand Abstract classes do allow you do add non abstract methods with out effecting the classes that extend it but if you add a method to an interface they all have to implement that method. So when should you use interfaces. I usually think about interfaces as behaviours. Interfaces are a bit like contracts, a guarantee that the a class that implements them will have certain methods, they might not have anything in but we won't worry about that here. The classic example of interfaces is implementing algorithm's, which in my mind is a classic textbook example which you read, understand but then can never make it relevant to your work because there aren't many times you need to implement a number of different algorithms. An example of interface implementation (in my opinion) is the sorting collections using the comparator. A quick summary of the comparator interface is used to order collections, it has two methods but I will just talk about compare(T o1, T o2) and it returns an int, Returns a negative integer, zero, or a positive integer as the first argument is less than, equal to, or greater than the second. It uses Generic functionality so T means a class. You extend comparator, implement the compare method which takes two objects you have made and then works out a way to decides whether the first object should be sorted higher than the second object. This is an excellent example of using an interface correctly, it is a behavior, it is not something you would want to be an abstract class because each class would probably want to overwrite the compare function. Another point to consider when thinking about using an interface is would other classes want to use this functionality. Abstract classes have firm hierarchy, Interfaces can be implemented by any class anywhere. Interfaces also have the advantage of allowing classes to implement many interfaces where as you can only extend one abstract class. This article offers a brief discussion on Intefaces versus Abstract Classes and this discussion gives a number of opinions from different people which is useful. Summary I think it depends on the functionality and purpose of your planned functionality. If you want to create some default behaviour and provide some base code with abstract methods for extending classes to implement then abstract classes are the way to go, which is why they are often used in frameworks. If you want to implement behaviour that could be used by many un related classes and you don't want a hierarchy for the classes that implement the code then you want to implement an interface. Obviously I'm not an expert and I just giving my opinion on a very complex topic, so please for give me if I have written anything stupid or completely incorrect, it was a very interesting topic to try and write about, also a very tricky one. I would like to people to comment on their ideas on how they decide to use Abstract classes or interfaces. I never use to like Interfaces because you would have to write the code for each implementing class but now I realise that if you use the interface in the correct way this is a good thing and interfaces allow you decouple your code and protect your code from changes by allowing it easy to change the code behind the interface, especially adding in new implementing classes and using them.
Nested Classes and how they work
One of the most confusing parts of Java our nested classes. The syntax can be very tricky with classes inside methods and methods overwriting others and semi colons on the end of curly brackets, the bottom line is it can be be very confusing. Nested classes are probably one of the biggest SCJP Java 5 exam gotchas out there. The Java exam has a will not compile option on every question and inner classes makes this option very tricky because there syntax can look wrong and make the code look like it won't compile. The examples are from the book Hardcore Java here is a link to the book if you are interesting in it http://www.oreilly.com/catalog/hardcorejv/I also linked to another free PDF from this book which is a sample chapter on using the final keyword. Click the link to read my blog on the chapter and there is a link to the free pdf on final classes http://hoskinator.blogspot.com/2006/04/hardcore-java-final-story.html. I really like the two sample chapters I have read from Hardcore Java here is a quote about the book from the OReilly website "Hardcore Java takes this language and breaks it apart, piece by piece, revealing the important secrets and tricks that will take you from a junior-level programmer to a seasoned and expert developer." nested classes in Java is one of the more confusing concepts and can make reading someone else's code very confusing, especially if you are not to sure how nested classes work. The chapter also squashes the myth/misinterpretation that Static nested classes are inner classes. With most things in Java the best way to understand the programming concepts being talked about is to give examples and this sample chapter gives lots of examples. if you don't understand inner classes I would recommend reading these articles because they can be very useful. The way I look at Inner classes is that they are like composition and using another class in your code, except the inner class has access to all of your private variables, which is a big advantage. If you are studying for the SCJP exam I definitely recommed you read these articles because you will see a lot of inner class code in the exam and you must be able to tell what is legal and illegal code otherwise you could be throwing away a lot of marks by not being able to spot the difference. The articles talk about these topics and each article looks at each topic in some depth Inner Classes Limited Scope Inner Classes Static Nested Classes Here are the links Nested Classes, Part 1 - Inner Classes http://www.onjava.com/pub/a/onjava/excerpt/HardcoreJava_chap06/index.htmlNested Classes, Part 2 - Limited Scope Inner Classes http://www.onjava.com/pub/a/onjava/excerpt/HardcoreJava_chap06/index1.htmlNested Classes, Part 3 - Static Nested Classes http://www.onjava.com/pub/a/onjava/excerpt/HardcoreJava_chap06/index2.html
Static classes in Java
This blog is about static code in Java and enclosing of constructor so it can never be instantiated and using what I call Static classes. I often wanted to create classes that weren't instantiated and I wasn't sure how to do this until I read Effective Java where one of the points it talks about is that. It still can be slightly confusing because you do still have a number of options, like Abstract classes, Singletons. I was thinking about this because sometimes need helper classes with static methods in, a class with useful methods but no variables. Often these classes are functions in one class but then I find I need that functionality in another class. This point I consider whether or not I want that class being dependant on the class that currently holds the method. I also consider does that class need that functionality, what is the role of that class. When deciding things like this I try and consider the rule "A class should only have one reason to change" although putting useful methods in a class is probably also breaking that rule, you have to put them somewhere and I would prefer the dependency to be on the helper class rather than a class which's main job is doing something else I find this helps me decide whether I should extract the function into another class. Sometimes if your classes are in a hierarchy you can pull up the method, enabling many classes below to be able to access the method. If your classes are not in a hierarchy or if other classes not releated to the class and many other classes would like to use it but it's not really enough to make its own class. These are the sort of naming, what package to put something in conundrums I sometimes get it and I sort of get frozen trying to think of a good name and where to put it. What I am talking about is basically a utility or helper class, which I'm sure many of you use. So basically you want to make a helper class with a useful static standalone method which people can call if they need it. What you don't want though is for people to instantiate this class. There are a few options, you could make it a singleton, you could make it abstract or you could make what I call a static class. The reasons why you don't want to make it abstract are because someone could subclass it. This is probably very unlikely because everyone will know it's a helper class because you have probably called it helper or utility. It's important to consider the design in more than just what's possible but as an intent of the use of the class. If I see an abstract class I think it's meant to be extended, someone has designed it that way. You also don't want people having to know you don't want them to instantiate it even thought its abstract but they should instantiate those other abstract classes because I want you to extend those. You could create a singleton, to ensure that only one object is created from the class. Singletons are classes with a private constructor's and often with a getInstance method which has code in to this also sends out the wrong signals (for this example). You create a singleton class ( public class ClassicSingleton {
private static ClassicSingleton instance = null;
protected ClassicSingleton() {
// Exists only to defeat instantiation.
}
public static ClassicSingleton getInstance() {
if(instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
} The class below is my so call static class
/**
* A helper class with useful static utility functions.
*/
public final class ActionHelper {
/**
* private constructor to stop people instantiating it.
*/
private ActionHelper() {
///this is never run
}
/**
* prints hello world and then the users name
* @param users name
*/
public static printHelloWorld(final String name) {
System.out.println("Hello World its " + name);
}
} So what's the difference between the two examples and why do I think the second solution is better for a class you don't want or need to instantiate. Firstly the Singleton pattern is very useful if you want to create one instance of a class. For my helper class we don't really want to instantiate any copy's of the class. The reason why you shouldn't use a Singleton class is because for this helper class we don't use any variables. The singleton class would be useful if it contained a set of variables that we wanted only one set of and the methods used those variables but in our helper class we don't use any variables apart from the ones passed in (which we make final). For this reason I don't believe we want a singleton Instance because we do not want any variables and we don't want anyone instantianting this class. So if you don't want anyone instantiating the class, which is normally if you have some kind of helper/utils class then I use the what I call the static class, a class with a private constructor and only consists of Static methods without any any variables. In some ways its a bit like a web services, you just use its methods and it converts the data you give it. I'm not sure what other people think about this or how they code their helper classes, please leave some comments and let me know.
SCJP 5 : Declarations, Initialization and Scoping aritcle
Constructor Initialization is the way to go
I read this article tonight on Martin Fowlers blog about ConstructorInitialization. http://martinfowler.com/bliki/ConstructorInitialization.html I have recently been favoring making objects immutable by passing in the variables the object needs and then only supplying getter methods for the variables. These objects are usually data objects used to pass around data fields that are related. It was since using the final variable more and reading Effective Java where it recommends you make objects Immutable as often as possible. I agree with this logical because a lot of the time once you have set the values you don't really ever need to change them again, so why do you need to supply setter methods. Not to mention that setter methods increases the chance of passing in null values. The article does state this as a reason for using this method "Constructor initialization is the approach where you try to ensure that you always create a class in a valid state by passing in all the collaborators that the object needs in the creation method of the object."
It does also have the benefit of creating thread safe objects. It seems odd really that so much documentation talks about encapsulation and telling everyone to put getter and setter methods around their private variables but you rarely here of them saying, create the class, initialize it with variables and then don't let them change it, put only getters in. I think they should, I think people should think about whether they will need to change an objects state (internal variables) at a later date and if they don't then don't put the setter methods on there. I view this decision a bit like making variables private which is hide as many variables as you can, the less developers can see and change the internal workings of your class the less likely they are to break it and find/create a bug.
SCJP 5 - Constructor revision sheet
As I was reading my Java SCJP book tonight, it kept mentioning things that I should definitely learn and read a few times. I often find that writing things down helps me to memorize bits of information so I was going to write down some of the more important points which I didn't already know. Then I thought I might as well do a blog entry on it, then not only would I benefit but I would also know where to retrieve the information again and it might help other people studying who stumble onto my blog. I also thought that if I blog about something that will be on the exam I will be still learning stuff for my exam rather than just blogging about something interesting. This way I will be learning stuff for my exam and blogging. It might not be that interesting to readers of my blog who aren't studying for the SCJP Java 5 exam or those who have already done the exam but I'm sure there will be a few facts here that you will have forgotten so give it a read. I was reading about Constructors this evening, now this is a fairly straight forward topic or so I thought because there are quite a few tricky little rules, which I certainly raised an eye brow to a few of them. The information below isn't a comprehensive guide on Constuctors but it's a sort of cheat sheet of the more tricky or must know stuff about Constructors. In my mind it's a sort of cheat sheet of quick facts about constructors, random facts for some quick revision. Constructors 1. Key points about constructors. - They have no return type - Their names must exactly match the class name (yes it is case sensitive) 2. Every class, including Abstract classes must have a constructor but you don't always have to type one, if you don't type any constructor then the JVM will automatically give you a no arg's constructor. 3. Constructors can use any access modifier which includes private. 4. You can have methods with the same name as a constructor. It is legal to have a method the same name as the class and the constructor 5. If you don't type in a constructor the compiler will automatically add one in for you, this will always be a no argument constructor. 6. If you have typed in a constructor the compiler will NOT add in the default no arg constructor, so don't try and call it. 7. Every constructors first line of code is either super() or this(). If this isn't the first line of code the compiler will automatically add this in 8. One of the constructors will always call the super class constructor (e.g. super()) if you call another constructor in the class then the super() will be prosponed until it go's into constructor that doesn't call another constructor. 9. You cannot call any non static variables/methods until after the super() constructor has run. You can use static variables/methods before this. 10. Interfaces do not have constructors 11. You can only invoke a constructor from inside another constructor 12. Abstract class constructors are called when the concrete subclass is initialized 13. The default constructor includes a no-arg call to the super constructor 14. Constructors are never inherited 15. Constructor cannot be overwritten but they are often overloaded. The Constructor Exam gotcha's Constructors cannot have return types, so if you see one with void, int, String etc, it isn't a constructor it's just a method. This is often used with tricky overwriting questions. They can be sneakily name the same Constructors MUST be the same name as the class. They are also case sensitive so watch out. If you have typed in a constructor the compiler will NOT add in the default no arg constructor, so don't try and call it. This is a sneaky exam trick, they show you a class with a compiler that has a constructor that takes some arguments and then they call a no arg constructor, bang error. You can only invoke a constructor from inside another constructor. If you see any method calling a constructor you know it won't work. The default constructor includes a no-arg call to the super constructor, this might be cause a problem if the super class doesn't have a no arg constructor, which means you will have to change this and add your own super constructor with parameters. So if you superclass doesn't have a no-arg constructor you can
An inner class is a nested class that is not explicitly or implicitly declared static. Inner classes may not declare static initializers or member interfaces. Inner classes may not declare static members, unless they are compile-time constant fields.
To illustrate these rules, consider the example below:
|
class HasStatic{
.....static int j = 100;
}
class Outer{
.....class Inner extends HasStatic{
..........static final x = 3;
..........// ok - compile-time constant
..........static int y = 4;
..........// compile-time error, an inner class
.....}
.....static class NestedButNotInner{
..........static int z = 5;
..........// ok, not an inner class
.....}
.....interface NeverInner{}
.....// interfaces are never inner
}
|
SCJP 5 Resource - Flow Control
This is probably one of the easier topics on the Java 5 exam because if you are programming in Java then you will have had to use the flow control (IF and SWITCH statements etc). The code also deals with the enum. This can be an exam nightmare because of all the extra things you can do with enums and the fact that it acts like a special class in many ways. It has the potential to provide some very tricky Java 5 exam questions so any information on this topic is welcome to me. The Enum is also allowed in switch statements, this can be an exam gotcha because you might think that this isnÂt allowed and they are trying to catch you out, in fact they are using the double bluff. Enums are one of the new features added in Java 5 that are both simple and complex at the same time. As soon as you see them you think cool, this is going to be really useful and then you see the examples or Exam questions on Enums and you think, oh my god look at all the possible syntax errors I could run into. Unlike some of the other features added into Java 5 Enums was done excellently and doesnÂt seem as much of a hack as the other features. The tutorial also explains the new enhanced for loop which is a piece of cake but you have to make sure you understand what is on each side of the enhanced for loop. Anyway here are the links, enjoy SCJP 5 : Chapter 2. Flow Control (Part-1) SCJP 5 : Chapter 2. Flow Control (Part-2) SCJP 5 : Chapter 2. Flow Control (Part-3) SCJP 5 : Chapter 2. Flow Control (Part-4)
SCJP 5 : Chapter 2. Flow Control (Part-5)
SCJP 5 - Switch Statements
I was curious about the effect of autoboxing on the switch statements and it has provided a potential exam gotcha. I was reading my SJCP book about control flow, if statements, switch statements and I was thinking to myself do I really need to read this stuff, I know it. But there are a few cheeky things in there. Like you are now allowed to use Enums as well as anything Int and below. Also if you use a byte you canÂt use a value higher than 127 otherwise it throws an error. I am a bit confused about the fact you need a constant. Initially I thought this meant the value you were testing in the select had to be a constant but now after a bit of investigation I understand (what a fool I have been) that the it's the case statements that need the constants. I have also found that if you are testing a btye value in the select then you have to have byte constants in the case. Usually you don't notice because you use ints. My investigation into the realms of the Wrapper classes and shown me that you can indeed use a wrapper class value in the select statement. Autoboxing unboxes the value and changes it to the primative. Finally a few Switch statement gotcha's 1. You can't have to case constants with the same value, it will throw a compiler error 2. Case Constants are evaluated from the top to the bottom. 3. The default constant can go anywhere and remember it is an entry into the code, so without any break statements it will run all the code below in the other case statements.
posted by Hosky at
1:35 AM
|
1 comments
links to this pos
Free PDF - varargs sample chapter
I have found a link to a sample chapter on the Java 5 feature - vararg also known as Variable arguments. This is also on the Java 5 SCJP Exam so anyone studying for that should give this chapter a read.
The chapter is from the book Java 5.0 Tiger: A Developer's Notebook By David Flanagan, Brett McLaughlin. The chapter talks about how to create and use variable-length arguments list. So it's a good resource for people wanting to study varargs for the SCJP Java 5 exam and also for people who are interested in writing varags code and using varargs
if you want a bit more VarArg action
There is also to a sun's tutorial on VarArgs this is from there Tech Tips news letter
VarArgs for people who haven't used them, allows you to pass a number (one or more) of types of objects into a method. So a simple example would be passing people's names into a method, some people who have one name e.g. Madonna (1 String) some people could have names with lots of middle names e.g. Benjamin James Hosking(5). It's quite a good feature and is quite useful in certain situations and better than having an array variable.
here is the link
http://www.onjava.com/catalog/javaadn/excerpt/javaadn_ch05.pdf
SCJP 5 - Autoboxing, Regular expressions and serialization articles
I have found some really useful links for the SCJP Java 5 exam. This article is well written and covers quite a few of the tricky areas of the Java 5 SCJP Exam. Even if you aren’t studying for the exam these article’s might still be of interest to you because they cover topics like Autoboxing, serialization, printf and regular expressions. Part 1 This link has information on the Wrapper classes added in Java 5 and the very useful Autoboxing and unboxing now make them a lot easier to use with literal variables (int, double, char etc) Part 2 Concentrates on the Java.io packages and reading files and using the BufferedWriters and readers. This is can be quite a tricky area in the exam because you need to know what order you use the classes. Part 3 This is all about serialization. I found this very useful because I don’t use serialization in my daily programming life, so it was a completely new subject and the more information I could read about it the better. Part 4 Is about using the Java.text package and formatting number, dates and Strings. Learning how to use the locale class so it transforms the data into the correct locale. Part 5 One of the nightmare areas for the exam, the fearsome Regular Expressions section. It also talks about the C style printf, which allows you to format you System.outs. SCJP 5 : Chapter 3. API Contents (Part-1) SCJP 5 : Chapter 3. API Contents (Part-2) SCJP 5 : Chapter 3. API Contents (Part-3) SCJP 5 : Chapter 3. API Contents (Part-4) SCJP 5 : Chapter 3. API Contents (Part-5)
Using the File class
I was doing some work on checking a directory for a file and then processing the file. This meant I had to use the Java's File class. It's a bit wired to start with having an object for a File especially in Java because File can be either a directory or file. I'm not sure whether having the File class be a directory or file is a good idea because it often means you have to check if a String directory path has created a File which is a directory or a File which is a file.
The File class is very easy to use and does have helpful isFile and isDirectory methods but it seems like you have to some extra checks. The advantage of course is that you can pass a directory and file about under the same Class. Thinking about it as I'm writing it probably isn't that much different from having a Directory and File class which extended an Abstract File class, you would still have to do some checking somewhere.
Don't get me wrong I'm not really moaning about it, I found the File class really good to use and it has some useful methods.
I found a really good page on the File class with useful snippets of code and a brief description of the methods you are likely to use.
http://mindprod.com/jgloss/file.html
I decided to make a static helper file with some methods which combined some of the File objects functions together, like making a directory and then a file and making a File instance from a String of directory and filename, checking it was exists, it was a file (not directory) etc. I'm not really sure about making static helper files but in this case I didn't want an object with an instance, just methods. Also the methods didn't hold any variables just took in a variable and returned a different one.
There are a few gotcha's with the file class. Here are the one's I can think of on top of my head
File can be a directory or a file.
If you pass in Null I think the file exists will return true.
You cannot delete a folder if there is a file(s) inside of it.
When you create a file with a new directory it doesn't create the directory, you have to use the mkdir() or createNewFile() methods
The deleteOnExit function only deletes when you code finishes, so I don't think you can use it between methods (e.g. in a junit test). I'm not totally sure when it deletes the file but I found that between my tests in a junit class the directory and file wasn't deleted.
One other bit of functionality that I like with the File class is each file has a deleteOnExit() function. This is good for writing unit tests or so I thought. I found that the folder or file is only deleted when the code exits. So this meant that I had to write a function which checked for and deleted the file and then folder.
Another interesting function the File has is that it can create unique temporary files and it gives each a file a random number on the front of it.
I quite enjoyed my time with the File class unlike some of the other classes in the Java framework this is very straight forward
SCJP toughest topic - Threads and Concurrency
Method overloading sample chapter - Free PDF
I found this good Java SCJP 5 resource today. I am nearing the end of reading my Java exam book Sun Certified Programmer for Java 5: Study Guide Exam 310-055 so at this point I am trying to keep an eye for test questions on topics in the exam. I like free pdf files and sample chapters so I was happy when I saw this free chapter on I found this sample chapter from JavaTM Programmer Certification Mock Exam by Dan Chisholm on Method Overloading. I think this chapter was for a book intended to be a mock exam for the Java 1.4 exam but most of it if not all will still be applicable for the Java 5 exam. Plus it is a few questions with explanations so it's good practice. Here is the link to the pdf file http://www.danchisholm.net/book/chapter12.pdfEven if you aren't taking the exam you can still learn about Method Overloading in more detail or answer the questions to see how much you do know.
Generics gotchas
I found this article tonight on Generic Gotcha's, this is a good article for people who haven't yet started using Generic's and for people studying for the Java SCJP 5 exam. I also have some links from the aritcle that point to some Free PDF files on Generics in Java. One of the best parts of any good article is the resources section and this article is no different because it has two links which are very good and they are discussed below. The article
http://www-128.ibm.com/developerworks/java/library/j-jtp01255.htmlis a brief look at the more tricky parts of Generics and in particular the places where it's a bit different from the rest of Java programming. It picks up on the things that you would assume would work but don't. I liked this article because it assumes you know the basics of Generics and just focuses on the tricky parts. The reason I like this article is because its exactly the kind of article i need on Generics whislt studying for the Java Exam. one of the biggest Generic Gotcha's is Generics are not covariant. Which means you can't put a subclass into a collection which specify's the superclass. The reason this is a gotcha because the rest of Java is covariant but I think once you understand the reasons for it, it makes sense. I think the biggest Gotcha in Generics is the wierd placing of the unusual looking angled brackets, I have said it before but it looks a bit of a hack job. Not that I'm saying I don't think it is a good addition, I do, it just looks wierd.
Below are two really good links taken from the article
Angelika Langer has created one of the most complete (in pdf or html) files on Generics I have seen, it is over 400 pages long and probably answers any question you have about generics. It deals with Frequently asked question and any other Generic question over thought up.
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.htmlGilad Bracha also has a good tutorial which at 23 pages is much more managable. I find this tutorial pretty good and easy to follow and it's from Sun so they should know what they are talking about. http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
Collections and Generics in Java 5
Collections in Java 5 is a fairly big topic and one of the tricky exam areas because there is lots of options and it comes down to knowing what collection you need for different scenario's. Collections is also made extra difficult in the Java 5 SCJP exam because Collections are heavily linked with Generics because one of the main motivations for adding Generics was to use Generics with collections. Although there is some data out there on these topics it can be quite difficult finding but I persisted and tracked some good resources down. So if you want some free pdfs on collections and generics, do I have some links for you. Collections Â? this is pretty good and goes into detail on each different kind of collection that will be covered in the Java 5 SJCP exam, e.g. lists, Maps, sets, queues. It is Nine chapters on collections
https://www.dev.java.net/files/documents/3557/16188/Collections.pdfthis is parts of a Java Generics book and it's pretty good, especially as on this topic there isn't that much data and I had to swap the words around in the google search to actually find some decent articles on the subject Complete draft of Java Generics, waiting for final comments https://java-generics-book.dev.java.net/files/documents/3557/21906/text-links.pdf
There has for Java 5 been a great deal of change with collections, mainly driven by the implementation of Generics in Java. I would also like to add that Java big cheese Joshua Bloch was one of the main people behind the changes, I am a fan of Joshua, particularly his book Effective Java. Anyway check him out http://java.sun.com/docs/books/tutorial/information/bios.html#jblochback to collections here is the classic sun tutorial link, I found the Sun Collections Tutorial quite useful although it did feel quite academic/clinical text book in some places but it is very through and has greater detail than you will perhaps need http://java.sun.com/docs/books/tutorial/collections/index.htmlif you are studying for the Java 1.4 exam or if you are using collections in Java 1.4 or Java 2 as it was known, then these articles from the Java Ranch should help you out, they are from the Java Ranch newsletter and are quite easy to read http://www.javaranch.com/newsletter/June2002/newsletterjune2002.jsp#collectionshttp://www.javaranch.com/newsletter/July2002/newsletterjuly2002.jsp#collectionshttp://www.javaranch.com/newsletter/Aug2002/newsletteraug2002.jsp#collectionshttp://www.javaranch.com/newsletter/Sept2002/newslettersept2002.jsp#collections
SCJP 5 - Collections / Generics Resources
Generic Epiphany - an Angled bracket vision
The past few days I have been looking at a lot of Generic code, reading articles about generics, looking at more generics code, snacking on generic code and washing it down with a nice generic drink and finally going to bed and dreaming about ...yes of course Generics. I have been reading all sorts of stupid examples about putting apples and pears into a fruitbasket and how the Doctors class is using generics to check the different animals but of course you can't just put a dog or elephant into an animal class oh no. I have blogged about Generics a fair bit, here is the last effort and it goes back through the others if you want a generic frenzy of information http://hoskinator.blogspot.com/2006/08/type-safe-collections-generics-arent.htmlI have kept plugging away with Generics and I have a decent grasp of it but one thing that I always had to double check was the placment of the angled brackets. Even copying out examples to play around with the code, I would often put the angled brackets in the wrong place. Anyway I was typing in an example and then all of a sudden, the angled brackets suddenly made sense, just like that, boom. It was a like a magic eye picture had suddenly come into view or when you look at the picture of the young woman looking one way and then suddenly realise that it can also be an old woman (if you have seen the picture you know what I mean, if not you probably think I'm mad) I understand the bit inside the angled brackets is the "type" but I often got slightly confused with the talk of the base type and then then the type but it's actually not as difficult as people talking about it seem to make out. I have found it's often easy to look at Generic code and reverse it (mentally) to non generic code and then see what you have got. so you have this List<String> myList = new ArrayList<String>();becomes List myList = new ArrayList();look at it this way helped me understand how Generics worked more clearly and simplified the angled bracket placing conundrum I had been experiencing. It also help me understand the base class they were talking about e.g. List and ArrayList (List is the Base class and ArrayList is the subclass). Looking at it now it seems fairly obvious and probably is to a lot of people out there but I now understand the angled brackets need to go anywhere where you are mentioning a class/object you are going to use e.g. List, ArrayList etc. so now I see the above so this List<String> myList = new ArrayList<String>();I now see base class type Variable name = new subclass class type ()but I find it helpful to take this code back to the non generic style to understand what is going on List myList = new ArrayList();Obviously this is an easy example and it can get very complex but here is another example A method example taking in an ArrayList public List<String> changeStrings(ArrayList<String> s) { }to this: public List changeStrings(ArrayList s) { }
Once again it seems easier to imagine the pre generic code show first and then adding it in to see what is actually happening in the code. I just thought I would share my Generic breakthrough on the blog in case anyone else was having a few problems with Generics, it's definitly one of the tricky sections on the SCJP exam I think.
Type Safe Collections (Generics) aren't so bad
I was reading some stuff about Generics and Collections and doing some boring study for SCJP 5 Exam and passing this exam really is the carrot at the end of the tunnel. I have read a number of blog entries about Generics and complaining that it's the opposite of Generic and that it's infact prohibative. Although I agree with this in some way but it doesn't really bother me and in fact I think that Generics works fine and if you create an List then it should only be able to accept JavaClass unless you wanna put a wild card ? and allow subclasses etc.
Although it is adding extra complexity and catches you out the first few times in the long run I think it makes it easier to understand because you can tell what is going to be in the Collection.
which I think is brilliant and have reviewed it here Anyway I read this linke
"Arrays in Java have always been type safe—an array declared as type String (String[]) can't accept Integers (or ints), Dogs, or anything other than Strings. But remember that before Java 5 there was no syntax for declaring a type safe collection" It's funny but I had never thought about arrays being type safe but they are. I think that any move to catch more bugs in compile time and making Collections type safe is just to catch any code which tries to put the wrong type of object into a Collection is a good thing.
I think Generics will be a sort of problem area for me in the exam because we don't use Java 5 yet at work so the only coding I have done with it is just mucking about. I have been writing small examples but it would be good if we could use Generics and Java 5 at work, fistly because it would give us some type safe collections and secondly because then I could practise writing code using Generics.
I have blogged about Generics before
and if you want some resources to learn about Generics and Collections, then look no further I have a blog entry with some links for you
and if that lots doesn't send you to sleep I don't know what will.
|
