Anupam Bhatt

Hi,

I am using ROME for pulling RSS feeds in my application and it works great. However, everytime i pull the feed, i get the complete feed(including read and old aritlces) and not just the new/unread/updated ones.

Is their a way by which i could get only the new articles and not the whole feed ?

The feed i want to pull does not set any "lastPublished" or similar data on the feed, it only sets "<lastBuildDate>" which gets refreshed everytime i pull the feed even if the articles are not new.

I understand i can filter articles by logic/date however that would still pull complete feed before filtering. I am trying to do the way google reader and other rss aggregation work.

Any help/info over this would be highly appreciated.

Thanks.

Campbell Ritchie wrote:The finally is better put inside the try, so you have two try blocks inside each other.

Yes true, the finally could be out associated with another try block and put inside the parent try block, but could you please elaborate on how it is better? i mean is it a good coding practice OR is it related to performance or something?

This may or may not resolve the issue you are facing, but the inputstream in isCompressed() should be closed to release resources.

try { ..... } catch() { ... } finally { in.close(); }

Note: You might need to handle the IOException too thrown from in.close()

For benefit, please let us know if it did resolved the issue.

Originally posted by jaspreet atwal:


Thanks for your reply Ernest! I can live with that...
I was just wondering if there is some logic behind all this, something that will help me keep this in my mind instead of cramming/memorizing it.

Hmmm....

Jaspreet,

I have slightly different answer to this, [may be would help you to understand it and not cram],

Interface methods are already/implicitly abstract, i.e. there is no implementation available, and abstract and static can't go to-gather.
Lets assume its possible, now consider abstract static method declared in an interface "MyInterface", now this gives a great chance to the caller to call the method by doing "MyInterface.myStaticMethod()", right ? which ofcourse would lead no-where/doesn't make sense.

To block such usage, you will have to block "static" modifier to methods in interfaces.
BTW, this is the same case with abstract methods in an abstract class too. Once again, abstract and static can't go to-gather due to the reason above.

Thanks, Raghavan and seetharaman for the reply.

I understand constructors can not be inherited etc., why i had asked this question was to ask this itself, is the reason only "doesn't make sense to be final" or is there some design/OOPS implications of allowing constructors to be final.

Looks like the only reason is "doesn't make sense to be final". Doesn't satisfy my quest though ! sigh !

Hi Again,

"A constructor cannot be abstract, static, final, native, or synchronized."

I understand on why it can't be all of the above, except "final".
why can't we have a final constructor, i understand constructors are not inherited, hence no chance/case of overriding etc. But why is it not allowed at all ?

Thanks all,

I think, the answer to my question was in:

"Which variable you get depends on the type of the reference to the object, and it's chosen at the time the program is compiled."

and

"The fact that you are storing a reference to an instance of ClassB as a ClassA does not change the semantics of the this operator."


Thanks again.
[ June 25, 2008: Message edited by: Anupam Bhatt ]

Originally posted by Bill Shirley:
PostRealCode

Didn't have any.. i just wrote the code to explain my doubts.

Hi Again,

I have developed this basic doubt and need some light over it...

Consider scenario:

[B]public ClassA {[/B] public String returnString() { return "Class A"; } public String dummyStr = "Hello from Class A"; [B]}[/B] public ClassB [B]extends ClassA[/B] [B]{[/B] // lets override returnString() method public String returnString() { return "Class B"; } // Lets override the dummyStr value too public String dummyStr = "Hello from Class B"; public void display() { // 1. Print the overriden field S.O.P(dummyStr); // 2. Print the original field from ClassA S.O.P( ((ClassA)(this)).dummyStr ); // 3. Print the output from overridden method S.O.P(returnString()); // 4. Print the output from original method, not the overriden one S.O.P(((ClassA)(this)).returnString()); } public static void main(String[]args) { ClassB obj = new ClassB(); obj.display(); } [B]}[/B]

The output i see is:
Hello from Class B
Hello from Class A
Class B
Class B < ------ have the doubt here


My doubt is, when we can access the original value for dummyStr [i.e the value assigned in the super class] by typecasting the ClassB instance to ClassA, why can't we access the implementation for the method in ClassA via typecast?

I understand i can get hold of the super class implementation for the method via the super keyword, but want to understand, why is the reference to ClassA obtained by typecasting, not executing the impl in ClassA.
[ June 24, 2008: Message edited by: Anupam Bhatt ]

yeah, agreed, and its clear now. Thanks all for the reply.. C you soon with another question/doubt

Great.. thanks for the clarification..

BTW any ideas on, what is so special about Arrays that they we made serializable by default? I mean most of the provided java classes are not serializable by design, so what is the thought behind making Arrays as serializable by default.

Hi,

Another quick question.

Consider an array with "non-serializable" objects as elements.

I do understand that arrays are serializable, but wondering what happens if the objects it stores do not implement serializable interface? Can the array be still serialized?

Hi,

Quick question, what is the difference between initialization of a variable and assignment of a variable. I would say "the first assignment to a variable is initialization", is that correct? views?

Oh BTW this question struck to me after reading this statement "A local variable must be explicitly given a value, by either initialization or assignment, before it is used. "

I am not sure, if it does have a effect, but did you try the procedure name in small letters and not caps, when calling from java? just a thought !

I thought again and i agree with you Peter, thanks for correcting me.

I was mixing two things here when talking about closing DB connections.

What we are freeing up on closing the DB connections is the connections to the DB so that we do not run out of DB connections for any further requests.

Just a clarification needed: where is the DB connection state held? I mean lets say we do not close a DB connection, in that case where shall the session data for the DB connection will be held? I think it would be held in memory on the DB server. Is that correct?

Need your comments.

Thanks,
Anupam
[ June 25, 2007: Message edited by: Anupam Bhatt ]