This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!

Lasse Reichstein Nielsen

Greenhorn
+ Follow
since Feb 22, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Lasse Reichstein Nielsen

Originally posted by rathi ji:
we are using Collection<?> it means it can take any object



No. Something with type Collection<?> is a collection of some type, but we don't know which. It could, for all we know, be a Collection<java.util.Date>.

Also, you can't create an object with runtime type Collection<?>. When we create a collection, we must pick some type for the elements, and not just say "don't know".

With generics, Collection<Object> is not a superclass of, or more general than, Collection<String>. Neither type of object can be type converted to the other, they are both too specific.

Instead we generalize by weakening the type argument. The most generic collection is Collection<?> (or, equivalent, Collection<? extends Object> ). There is no objects with this type, but there are objects that are comatible with it (a collection of any chosen type).

We can then make a less generic type, like Collection<? extends String>. Any collection of any type that matches this type, will also match the previous one. Again there is no objects of this type.

More precise again is Collection<String>, of which you can make objects, because the type is known exactly. That means that we have a hierarchy of collection types with exact types at the leaves, and more general types in the nodes, and we can only make instances of the exact types.

Regards
/L

Edit - formatting
[ March 11, 2005: Message edited by: Lasse Reichstein Nielsen ]
Recognizing e-mail addresses is hard, bordering on impossible. The only real reference to what an e-mail address can look like is the SMTP specification (RFC 2821), and that is very forgiving. Anything on the form <localpart>@<domain> is acceptable.

I usually recommend going with just:


That accepts all of these (perfectly valid) addresses:
  • me+something@example.com
  • me.something@[192.168.10.2]
  • "Mr.Jones"@example.com


  • The parts before the "@" should only ever be interpreted by the
    receiving host, so you shouldn't try to rule something out (except
    extra "@"'s). The part after the "@" can be a domain name or an
    IP-address (both IPv4 and IPv6).

    Also remember, that there is no way to ensure that an e-mail address works, i.e., that it can receive mail, except trying to send to it and receive an answer. On the other hand, it is far too easy to reject a perfectly good and working address, which will make the user of the page a lot of pain and cursing ... not something to aim for.

    Aim to accept too much rather than too little. The worst that can happen is that the mail bounces or is lost, and that will probably happen for foo@example.com too.

    /L
    Using is not the best way to check for being numeric, since it allows trailing garbage in the argument (e.g. would yield 2.2).

    There is also no reason to do a . You already have a boolean, so a simple negation would suffice (pet peeve, sorry .

    When converting a string to a number, I recommend using the function. A (very slightly) more efficient method is to use the prefix plus operator. More on converting to numbers can be found in the comp.lang.javascript FAQ (it's a great FAQ, read it all!).

    So:


    That accepts all strings that are number literals in Javascript. Often when someone wants data to be numeric, they have a specific format in mind. If the format is simple, using a regular expression on the string might be more efficient than converting it to a number that isn't used anyway. E.g., to check whether a string is an integer numeral:



    Regards
    /L