Search Results

Search found 3 results on 1 pages for 'skrebbel'.

Page 1/1 | 1 

  • How to read iptables -L output?

    - by skrebbel
    I'm rather new to iptables, and I'm trying to understand its output. I tried to RTFM, but to no avail when it comes to little details like these. When iptables -vnL gives me a line such as: Chain INPUT (policy DROP 2199 packets, 304K bytes) I understand the first part: on incoming data, if the list below this line does not provide any exceptions, then the default policy is to DROP incoming packets. But what does the 2199 packets, 304K bytes part mean? Is that all the packets that were dropped? Is there any way to find out which packets that were, and where they came from? Thanks!

    Read the article

  • javadoc and overloaded methods

    - by skrebbel
    Hi all, I'm developing an API with many identically named methods that just differ by signature, which I guess is fairly common. They all do the same thing, except that they initialize various values by defaults if the user does not want to specify. As a digestible example, consider public interface Forest { public Tree addTree(); public Tree addTree(int amountOfLeaves); public Tree addTree(int amountOfLeaves, Fruit fruitType); public Tree addTree(int amountOfLeaves, int height); public Tree addTree(int amountOfLeaves, Fruit fruitType, int height); } The essential action performed by all of these methods is the same; a tree is planted in the forest. Many important things users of my API need to know about adding trees hold for all these methods. Ideally, I would like to write one Javadoc block that is used by all methods: /** * Plants a new tree in the forest. Please note that it may take * up to 30 years for the tree to be fully grown. * * @param amountOfLeaves desired amount of leaves. Actual amount of * leaves at maturity may differ by up to 10%. * @param fruitType the desired type of fruit to be grown. No warranties * are given with respect to flavour. * @param height desired hight in centimeters. Actual hight may differ by * up to 15%. */ In my imagination, a tool could magically choose which of the @params apply to each of the methods, and thus generate good docs for all methods at once. With Javadoc, if I understand it correctly, all I can do is essentially copy&paste the same javadoc block five times, with only a slightly differing parameter list for each method. This sounds cumbersome to me, and is also difficult to maintain. Is there any way around that? Some extension to javadoc that has this kind of support? Or is there a good reason why this is not supported that I missed?

    Read the article

  • casting Collection<SomeClass> to Collection<SomeSuperClass>

    - by skrebbel
    Hi all, I'm sure this has been answered before, but I really cannot find it. I have a java class SomeClass and an abstract class SomeSuperClass. SomeClass extends SomeSuperClass. Another abstract method has a method that returns a Collection<SomeSuperClass>. In an implementation class, I have a Collection<SomeClass> myCollection I understand that I cannot just return myCollection, because Collection<SomeClass> does not inherit from Collection<SomeSuperClass>. Nevertheless, I know that everything in myCollection is a SomeSuperClass because after all, they're SomeClass objects which extend SomeSuperClass. How can I make this work? I.e. I want public class A { private Collection<SomeClass> myCollection; public Collection<SomeSuperClass> getCollection() { return myCollection; //compile error! } } The only way I've found is casting via a non-generic type and getting unchecked warnings and whatnot. There must be a more elegant way, though? I feel that also using Collections.checkedSet() and friends are not needed, since it is statically certain that the returned collection only contains SomeClass objects (this would not be the case when downcasting instead of upcasting, but that's not what I'm doing). What am I missing? Thanks!

    Read the article

1