Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!

Sudhir Srinivasan

Ranch Hand
+ Follow
since Jun 08, 2011
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sudhir Srinivasan

Jayesh A Lalwani wrote:
FOr not you can just copy the myapp folder where you want it to go. It should still work

As suggested, copied the my-app directory to the folder of my choice i.e E: . Then in the command prompt

switched to the folder concerned and ran the project successfully. So, simply copy pasting the project does work!

While your latter suggestion worked, the former

Jayesh A Lalwani wrote:
When you create the project, run the archetype:generate in the folder that you want to generate the project in

one resulted in the same output (that I encountered initially), namely,

So, I switched to the maven installed directory

and ran the archetype:generate command

to successfully

build (using the maven lib jars from the installed local repo) and execute the project.

To Summarise:
a) I'm able to copy paste existing project from maven dir to folder of my choice i.e E: and execute the project
b) I'm able to build (& execute) a new project from within the maven installed directory (as shown above)
c) to build a new project in a folder, E:, distinct from the maven installed directory. What gives???

Could you please explain and also help resolve this confusion.

FYI again:
JDKs installed -
Path: C:\Program Files\Java\jdk1.8.0_40 (for 64-bit O.S)
Path: C:\Program Files (x86)\Java\jdk1.8.0_40 (for 32-bit browsers)

Maven installed dir -

Many Thanks,
6 years ago

Thank you for your response.

Jayesh A Lalwani wrote:
Anyhoo do this: First of all close all your command prompts. Just close them. And open a new one. Then run mvn --version
and java -version in both folders and then post back what you get.

Per your recommendation, I closed the command prompt restarted the system and opened a new one. On running java -version
and mvn --version in respective directories

the results appear to be the same.

On running the generate command following maven lib jars (have not reproduced the download
in order to keep my post short)

downloaded from central repo to local repo (.m2 folder created) on successful execution of generate
from the command line and

also the successful creation of the first project.

This once again downloads all the maven lib plugins required for packaging the project (my-app)

and the successful jar file generation at the location

Tested the newly compiled and packaged (project) JAR

to get the output

This certainly solves the issue at hand. Many thanks Jayesh!


This has installed the my-app project within the maven installed directory. How does one create the project
outside the maven directory?

6 years ago

I'm new to maven and have just installed maven 3.3.1 on my windows 7 computer.

I've followed the download and installation instructions given here.

From my research on google / the web, I've setup the maven environment variables [by right-clicking my computer > properties >
advanced system settings > System properties > Advanced tab > Environment variables and under System variables] as

I've appended the java and maven bin directories [separated by semi-colon] at the end of the System variable, Path .

From the getting-started-guide-apache-maven-in-5-minutes page, I've also verified maven installation by

by opening the command prompt window and entering the mvn --version command which shows its successful installation.

However, when I tried to generate the first maven project [quintessential Hello World program] from another directory with
archetype:generate command, I'm getting the following

instead of the jars being downloaded from the maven central repo & the project being built. Naturally, on checking E drive, neither the
project directories (and their paths) nor the m2 [local repo] folder been constructed.

Again, looking closely here led me to these windows prerequisites vis-a-vis installing maven on windows O.S. As maven is java-based,
the windows prerequisites requires
both java and maven to be installed in directory paths that do not have spaces inbetween them. While my maven installed directory
D:\apache-maven-3.3.1 conforms, the jdk installed directory is C:\Program Files\Java\jdk1.8.0_40 [i.e Program Files contains space inbetween].

Other details:
O.S: Windows 7 64-bit
Java installed:
  • x64 for 64-bit O.S Path: C:\Program Files\Java\jdk1.8.0_40
  • x86 for 32-bit browsers [firefox, chrome, IE] for running applets and other 32-bit compatible apps Path: C:\Program Files (x86)\Java\jdk1.8.0_40 .

  • JAVA_HOME: points to the x64 jdk installed directory

    Why is it I'm unable to build the project from the command prompt? Is it because of
    a) the jdk location [i.e being installed in Program files] and / or
    b) existence of two jdk's [32-bit & 64-bit] research on the web shows a) and b) are perfectly OK vis-a-vis java download and installation
    c) any other reason I'm missing

    Much appreciated if any of the forum experts help me in resolving this [without, hopefully, advocating change in java jdk setup].


    6 years ago

    Campbell Ritchie wrote:

    Sudhir Srinivasan wrote: . . . How do they operate on booleans? . . .

    As logical and and logical xor and logical or and and and

    In my defense, the question arose due to my confusion between the short-circuiting AND, OR operators and the not short-circuiting AND, OR operator
    and the internal distinction of the latter [as integral types and as boolean logical types] which has been clarified by the

    Campbell Ritchie wrote:Java Language Specification (JLS) J7 again.
    Those bits of the JLS have been surprisingly clear, haven't they!

    JL specs, again, and by researching the web. The operators, & ^ | operate internally not only as integral types [which is what my
    first post focused on] but also as boolean logical operators when both operands in the shift operation are of type boolean or Boolean.
    7 years ago

    Campbell Ritchie wrote:
    153 ÷ 8 =   19
    153 × 8 = 1224

    Only people get confused between ^ used to mean exponentiation and ^ meaning XOR. Look here for a bit more information about superscript numbers...

    Thanks for pointing that out . It indeed would mislead many people [except those who understand the context in which it is used and they would only be a few experts like yourself]. The link provided, again, is very useful.

    left-shift == left-operand * 2.
    signed right-shift == left-operand / 2.

    Campbell Ritchie wrote:...I have failed to find superscript n, however.

    This, hopefully, sets right the anomaly above.
    7 years ago

    Campbell Ritchie wrote:
    That link's not javadoc, but the Java Tutorials.

    Oops! You're right.

    Campbell Ritchie wrote:
    They are useful for masks, rapid remainders by powers of 2, particularly when you want to go from hash code to array index (never < 0, never ≥ array.length, so never throws out of bounds exceptions), cyphers, etc. As the link you posted shows, they are less useful to beginners.
    Left shift moves the MSB off the number so it is going to vanish anyway, and unsigned right shift is programmed to shift in 0s. Probably done somewhere on the chip. Don't know any more. As far as I know they are all implemented similarly, probably at the level of the chip with NOT, AND, OR, XOR and shift circuits. Don't call left shift signed;......

    The java tutorials seems to call << operator 'signed' while the scjp tipline and the java language
    specs conform to what you've said simply 'left-shift' operator. I guess I'll go with the latter and your post.

    Campbell Ritchie wrote: is only right shift that is signed or unsigned. Signed right shift maintains + as + and - as -. Unsigned right shift if both operands are not 0 gives a positive result. Left shift can give + or - depending on whether you get overflow and (if you keep shifting to the left long enough), will give you 0.

    Does this mean >> operator is more ideal for signed twos complement binary numbers while the >>> operator is more useful for only positive numbers. In other words,
    for n >>> s, if n is negative, result of shift operation would still be positive as unsigned right shift is anyway programmed to shift in 0s which would cancel out the sign bit.

    Campbell Ritchie wrote:
    You will realise that if left shift is like repeated doubling, signed right shift is like repeated halving.
    i >> 3 equals i ÷ 2³ with the usual conventions of integer arithmetic.

    Got it. left shift is equivalent to left-operand * 2^n while signed right-shift is left-operand / 2^n where 'n' is the shift distance.
    7 years ago

    Campbell Ritchie wrote:You are right about & ^ |. Remember their precedences, and that they are overloaded to operate on booleans, too.

    How do they operate on booleans?

    Campbell Ritchie wrote:
    Yes, it is a certain number of bits, but you need to go through the Java Language Specification (J7 edition) to find out how many.

    Thanks for the link. Certainly provided the much needed clarity.
    In the case of int [size 32-bit i.e 2^5] - &ing of the right-hand operand with the bit mask 0b11111 ensures that the shift distance is always in the range 0-31 inclusive
    which conforms to the size of an int. This explains the use of only the 5 lowest order bits of the right-hand operand in any case.

    In the case of long [size 64-bit i.e 2^6] - &ing of the right-hand operand with the bit mask 0b111111 ensures that the shift distance is always in the range 0-63 inclusive
    which conforms to the size of a long. This explains the use of only the 6 lowest order bits of the right-hand operand in any case.

    As the result of the shift operation depends on the implicit casting to an int or long of the left-hand operand, the shift distance would naturally conform to either of the two
    sizes and not go beyond the respective ranges.

    Campbell Ritchie wrote:
    In the case of … where i and j are both integer primitives, the number of bits shifted is always j & size - 1, where size is the number of bits in i after promotion, 32 for anything other than a long. That means that only the rightmost 5 (6 for a long) bits in j are used to determine the distance to shift. Although you have shown 8‑bit numbers, the shift operations would promote them to ints. If you haven't come across i & j - 1 before, it is a bit like i % j, but j must be an integer obtainable from 2, and the result is always ≥ 0. Does that answer your question about negative shifts? They will be converted to 0 or a positive number less than the number of bits in the left operand.

    Yes, it certainly answers the one on negative shifts. As I've understood [as shown in my reply to your post above], the shift operations automatically promote the shift value to
    an int or long based on the type of the left-hand operand [being an int or long only] which in turn determines the outcome of the shift operation.
    7 years ago
    At the outset, thank you Campbell for all your responses.

    Campbell Ritchie wrote:Try it like this
    ~0b0000_0001 == 0b1111_1110
    … and it becomes a lot clearer.

    Oh yes! Java SE 7 and later now includes binary literals as part of the existing integer literals [decimal & hexadecimal].

    The following code

    and its output

    shows the decimal equivalent - being the number system in use most of the time - of the binary values. Java SE 7 (& later) simplifies the use of binary values.
    However, I must add that learning its internal workings as shown on scjp tipline and other content on the web makes understanding the code above that much
    easier. Case in point: Looking at the code snippet that uses ~ operator to negate the bits of the binary literal, I wouldn't have a clue as to how 1
    became -2 if it were not for the behind-the-scenes insight.

    7 years ago

    I'm learning java's bitwise [AND, OR, XOR] and bitshift [<<, >>, >>>] operators and my program is an attempt at understanding the same.
    My program implements by attempting to emulate the behind the scenes working of these operators and give the desired output.

    A) My research:
    From the web, starting with Corey McGlone's article on bitshifting, I moved on to wikipedia's content on two's complement, one's complement,
    bitwise & bitshifting operators and a few other websites relating to the same.

    B) What I've understood:
    bitwise operators - operate on corresponding individual bits of the bit patterns or binary values. It is a low level operation performed directly at
    the processor level.
  • bitwise NOT [~]:
  • flips or inverts the individual bits of a binary value i.e 0 to 1 and 1 to 0. In other words, performs the ones complement to
    the bits of the bit pattern [8-bit byte where the 8th bit is the sign bit]. Applying the ~ operator to a decimal value, say 1,
    gives ~x = -x-1 where x == 1. So, ~1 gives -2. In binary

  • bitwise AND [&]:
  • &ing of bits returns 1 when corresponding individual bits are 1 otherwise returns 0.
  • bitwise OR [|]:
  • |ing of bits returns 0 when corresponding individual bits are 0 otherwise returns 1.
  • bitwise XOR [^]:
  • ^ing of bits returns 0 when corresponding individual bits are 0 and corresponding individual bits are 1
    [here 1 is carried to the next MSB].

    bitshift operators - shift or move the bit(s) a certain number of positions to the left or right. The bit(s) shifted out are [discarded and] replaced by the
    same number of bit(s) at the other end i.e shifted in at the other end. So, in

  • >> operation:
  • bit(s), in a binary value, shifted out on the right are discarded. The existing bit(s) move n positions to the right [as the shifted out bit(s)]
    thereby facilitating the shifting in of bit(s) at the far left. Here, bit(s) shifted in depend on the signed magnitude or sign extension[>> operator preserves the sign]
    of the binary value. 0 is shifted in if the sign bit [aka MSB] is positive and 1 if the sign bit is negative.
  • << operation:
  • this is the reverse of the >> operation. bit(s), in a bit pattern, shifted out on the left are discarded and the same number of bit(s) are shifted
    in at the far right. Here, the sign bit is ignored and 0's are always shifted in to the far right.

  • >>> operation:
  • this operates like the << operator. bit(s), in the binary value, shifted out on the right are discarded and 0's are always shifted in at the
    far left ignoring the sign bit.

    C) My program:
    As the program is humongous [excessive use of StringBuilders, arrays, for loops, nested for loops etc. within the **methods*], I've posted the pseudocode
    that I wrote down on paper before implementing the same in the program. The pseudocode is only a broad contour and not a step-by-step instructional for
    program implementation.
    If required for the sake of clarity, shall post the entire program code.

    **methods* - methods that implement program logic and those that print the results on screen, step-wise.

    The program is the culmination of researching various java concepts on the web

    and the resultant static methods written, tested, compiled and run individually before implemented in the program. Each method performs a specific, albeit
    sometimes lengthy, task and returns the result.

    D) Program pseudocode:

    and its successful output

    For positive shift value

    For negative shift value

    To implement negative shift value, a few additional steps are inserted into the original pseudocode.

    E) My questions / doubts:
    1. Java being a higher level language, are such processor level operations useful in java programming? If yes, in which situations are they useful i.e
    when can they be used?....given that even the javadocs devotes only a single small web page to it.

    2. Why do the signed left-shift operator & unsigned right-shift operators ignore the sign bit and always shift in 0's [unlike the signed right-shift operator]?

    3. How does the signed shift operators [right and left-shift] differ from the unsigned right-shift operator?....i.e do they all operate at the bit level or does each
    operator conduct the shifting process in a different manner behind the scenes.

    Much appreciated if the responders / moderators give answers with sample code.

    7 years ago

    Winston Gutkowski wrote:

    Sudhir Srinivasan wrote:The updated code snippets based on my understanding of your suggestions.


    It's too late for this thread, I suspect, but for future reference: Please DontWriteLongLines.

    Hi Winston,
    I've edited my last post and shortened the lines as suggested.

    I shall certainly keep your suggestions in mind when posting in the future. Any inconvenience caused to the moderators / responder(s)
    is regretted.


    8 years ago

    Richard Tookey wrote:Though I can't see your latest code so I can't be certain....

    The updated code snippets based on my understanding of your suggestions.

    Sudhir Srinivasan wrote:At the time of building the map object sendMap, by looping thru
    the String[] str & adding the key-value pairs to this object,...

    Richard Tookey wrote:You
    just need to normalise each one when using it as a key in the Map! You normalise the String[]
    entry when building the Map...

    Sudhir Srinivasan wrote:In the GetValues class, when setting the respective field
    within the setter method,....

    Richard Tookey wrote:and you normalise the user's input
    when looking up the value in the Map.

    Sudhir Srinivasan wrote:In the MapTxtToInt class,

  • just set (& return) the (normalized) map object sendMap passed from

  • ......check for String equality of normalized user input with that of the keySet
    of the normalized map object.

    Richard Tookey wrote:and you normalise the user's input when looking up
    the value in the Map.

    8 years ago
    Okay. I think I've got it. Modifying the Pseudocode in my previous post

    Richard Tookey wrote:You don't need to modify the String[] containing the alpha representations!

    the String[] str containing the original values (with hyphens / space).

    Richard Tookey wrote:You just need to normalise each one when using it as a key in the Map! You normalise the String[]
    entry when building the Map

    At the time of building the map object sendMap, by looping thru the String[] str & adding the key-value pairs to this object, replace each
    array element - containing hyphen / space - with empty string. Converts all the text, within the map, into a common form with the
    corresponding values.

    Richard Tookey wrote:
    and you normalise the user's input when looking up the value in the Map.

    In the GetValues class, when setting the respective field within the setter method, replace the hyphen / space with empty
    string. Converts the user input to a common form.

    In the MapTxtToInt class,
  • just set (& return) the (normalized) map object sendMap passed from TestNaturalLanguageMultiply
  • within the getter methods,

    Sudhir Srinivasan wrote:
    - attributes inherited from GetValues
    - getter method 1:
    .. Iteratively, for each String output [output being variable name] in the keySet of tempMap
    .. check for String equality of user input 1[access & get superclass method] with output. If true..........

    check for String equality of normalized user input with that of the keySet of the normalized map object. If true,
    get the values corresponding to the same & do the calculation.

  • This obviates the need
  • for creating a separate map object and also
  • for lines of pseudocode [12-17] of MapTxtToInt in my previous post

  • [sidebar]
    If I've still not got it right (*sigh*), could you please provide the sample code (Richard, a big thank you for your time
    and patience)
    that simplifies my program as suggested.

    Program output:
    8 years ago

    Campbell Ritchie wrote:
    Why are you trying................ Don't try to do the whole thing all at once. Do it in bits, and write
    methods which test each part before the app is complete.

    From Campbell's suggestions,

    the Pseudocode [for OOP based application]

    and its program output

    Please Note:
  • All classes to be within the same package of the project.
  • Fields / variables within the classes to be private & accessible only thru their respective methods.

  • I hope the pseudocode is not incomprehensible and complicated. Although a trifle lengthy [in my attempt at ease &
    simplicity], I think it can be translated to actual code without too much effort.

    I've modified the String[] to contain values without hyphens / spaces corresponding to user inputs. An update to the pseudocode would be
    to incorporate hyphens / spaces to be matched to the user inputs

    Richard Tookey wrote:Since you will only ever lookup an integer using the alpha representation of the integer you only need one
    Map<String,Integer>. That use as key the normalised alpha representation with hyphens and spaces removed (a simple regex will do this)............

    by way of a simple regex expression as suggested by Richard. Will post the same on completion.
    8 years ago
    As per Richard's suggestion

    Richard Tookey wrote:Why not just remove all spaces and hyphens from the input supplied by the user and from the keys
    when generating the map.......... This way you just have to replace all spaces or hyphens with the empty string; a simple
    one line regular expression.

    this pseudocode (of sorts, if one may call that)

    a) for the removal of hyphens / spaces at the time of generating the map

    b) for the calculation part

    provided would display the result without bothering about hyphens / spaces in the text (user input to omit hyphens /
    spaces for ex: twentyfive, seventytwo etc..etc..etc). The code derived from this (hope the pseudocode is not complex or
    incomprehensible) replaces the lines of code 58 to 130 in my original posting. It certainly shortens the code from 72 lines to approx. 20 lines.

    and output from program

    To further refine the code, will work on Campbell's suggestions

    Campbell Ritchie wrote: Start by reducing the main method to its ideal length: 1 statement. Create a class or some classes which will encapsulate your logic. One will have the Map as a field. Create methods to input the two numbers and the operator, and to do the calculation...........

    (adhering to java fundamental, OOP) and revert.
    8 years ago
    Thank you Matthew, Richard and Campbell for your prompt responses.

    As you have quite a few suggestions for modifying and improving the program code, will need some time for the same. Will revert with modified code once completed.

    8 years ago