Anastasia Sirotenko

I try to load an xsl file with classLoader, but Test.class.getResourceAsStream("test.xsl") always returns null. Then i copied the test.xsl file to test.png - and that one works fine. Can anyone explain me how it can happen?

Here is the test case: two identical files with different extensions reside in the same package, and classloader works with different results:

import java.io.InputStream; public class Test { public static void main(String[] a){ InputStream xslStream = Test.class.getResourceAsStream("test.xsl"); InputStream pngStream = Test.class.getResourceAsStream("test.png"); System.out.println("xsl: " + xslStream); System.out.println("png: " + pngStream); } }
The output is:
xsl: null
png: java.io.BufferedInputStream@3d84ec44


UPD: The problem found - i was lounching this from IDEA and it was misconfigured: Resource patterns setting included *png but didn't include *xsl

I believe it is enough to remember all checked exceptions that are mentioned in K&B book (in exceptions' chapter, in chapters on I/O and concurrency). Other than that exceptions will be given with hierarchy, like:

class MyException extends Throwable{} class MyOtherException extends RunTimeException{} // some code with those exceptions

vineet walia wrote:it is not width try change argumnet 7 and then 7267 ?

It is width. You can call it "minimum width". If argument's width extends it, it is ignored. Try to put 010 instead of 01, see the difference.

Here what your method should look like:

public static <Declare new Generic type> Collection<Type of return value> getLongWords( Collection<Type of parameter> coll ){ }

now look what you've got:
public static <E extends CharSequence> Collection<E super String> getLongWords( Collection<E> coll ){ }
<E extends CharSequence> - type declaration ok
Collection<E super String> - another type declaration? it is not the right place to declare new type where the return type should go
it would be legal to put here <? super String> though, as that is what type wildcard looks like
Collection<E> - type of parameter is ok, it was previously declared

public static <E> Collection<E extends Number> getLongInts( Collection<E> nums ){ }
<E> - type declaratin is ok
Collection<E extends Number> - one more type declaration where it should not occur
it would be legal to put here <? extends Number> though, as that is what type wildcard looks like
Collection<E> - valid parameter type, which was declared first.

PS. And don't forget that since you declared return type, you should return something from both methods...

Congratulations, keep moving!

Harry Henriques wrote:I just wanted to make sure that this isn't a Java 6 feature ONLY.

It is same for java 5.
by the way, you can get any older jdk and manage your IDE or OS to run them

Harry Henriques wrote:Thanks for your reply, Sebastian. But the code below compiles and runs just fine. I instantiate an implementation of interface Range and an implementation of interface Grassland. The output is below in red.

You not clearly understand what means "can not extend more then one class or implement more then one interface"
The extended class can implement lots of interfaces itself, or implemented interface can extend from lots of other interfaces. Just like it shows in your code.
You certainly can do this:
Range R = new Range(){ public void graze(){ // implements exactly 1 inteface Range, Range itself can extend lots of interfaces System.out.println("graze3"); } }; Grassland G = new Grassland(){ public void munch() { // implements exactly 1 inteface Grassland, Grassland itself can extend lots of interfaces System.out.println("munch3"); } };

But you cannot do something like this:
Range R = new Range, Grassland(){ // you cannot implement more then 1 interface or extend more then one class public void graze(){System.out.println("graze3"); } public void munch() {System.out.println("munch3"); } };

Grats!

Just gave the exam, got 90% and feel good 8]
Want to thank Kathy Sierra and Bert Bates for their book and Devaka for a great ExamLab simulation.
And of course thank to all you ranchers who helped me to clear some topics and those who asked questions which i got to clear too.

it means that when your code is like
Integer i = 1; i +=1;

internaly it goes like
Integer i = 1; Integer j = i+1; i = j;
The values that contained in the wrapper don't change, when some operations are made on them, it means new wrapper objects are created and assigned to you wrapper references.

krishna Mohan Athota wrote:
An abstract "Inner Class" is also an abstarct element. So i beleive we should modify the class outer also with abstract modifier. why we are not geeting the compilation ERROR?

Inner classes are not like methods, the are classes. When you declare abstract inner class, you can declare its subclasses in the same outer class, and implement different inner class realizations, and use all of them in your outer class as needed. You can even have abstract private inner class, since all it's subclasses can be implemented inside the same outer class.
Remember you cannot have abstract private methods, cause abstract methods are all due to overriding in some descendant classes.

NullPointer comes from line 8, where you try to instantiate gb1.g.g , tho gb1.g is null after line 7

3 objects:
2. Garb g; 3. public Garb(Object g){ 4. this.g=(Garb)g; 5. } 6. public static void main(String args[]){ 7. Garb gb1=new Garb(new Garb(new Garb(null))); // gb1 -> [Garb].g-> [Garb].g -> [Garb] 8. gb1.g.g=new Garb(new Garb(null)); //gb1 -> [Garb].g-> [Garb].g -X-> [Garb] // here we get 1 object for GC, X is for link broken //gb1 -> [Garb].g-> [Garb].g -> [Garb].g-> [Garb] 9. Garb gb2=new Garb(new Garb(new Garb(gb1))); //gb2 -> [Garb].g-> [Garb].g -> gb1 10. gb2.g=gb1.g; //gb2 -X-> [Garb].g-> [Garb].g -> gb1 // here we get 2 objects for GC, X is for link broken //gb2 -> gb1 11. System.gc(); 12. } 13. }

Nitish Bangera wrote:labelled break can be used for any code block but the necessary requirement is it should break the codeblock with that label. labelled continue can only be used for loops with the same label.

Thank you for clearing, Nitish and Ankit, got it 8)

Sebastian Janisch wrote:The break statement has no effect.
Note that you are labeling an if statement not a loop (also why continue won't compile).
As your code stands it does thw following.
label: if(condition) { break label; }
Your code breaks out of an if statement that would have ended anyway.

I tried this after finding the illustration: (source)
// if there is code between a loop and label it will compile fine if enclosed in {} loop : { // (1) System.out.println("test"); for (;;) { break loop; } } //(2) // if remove (1) and (2) the code will not compile
And it breaks fine from while loop, which is actually labeled, it prints 8, then breaks, then just for loop procedes. The if statement stands instead of {} here, i assume.