Tim Cooke wrote:I have no idea what CharArrayReader does behind the scenes

Dammit!!!

Campbell, indeed it is.:

Unfortunately using .equals() doesn't get us off the hook either.

(Taken from my JDK 1.7 source.)

Matthew Brown wrote:How do we feel about things that probably use the length property under the hood

Probably hard to avoid it. Even Campbell and I's use of string.substring(1) almost certainly calls string.substring(1, string.length()) under the hood too. I have no idea what CharArrayReader does behind the scenes but I imagine it knows the length of it's current buffer which may or may not be the full length of the character array.

A variation on the last one. If the Java compiler ever supports tail recursion optimisation then this one would win out over the last as it would occupy constant stack space. Although String concatenation is inefficient over using the StringBuilder which I used in one of my other solutions.

OK. That's my lot.

How about some more recursion with a more Functional Programming approach.

With recursion

I came up with a couple of solutions.


I like the first better because it does not rely on Exception handling for flow control.

Minjae Kim wrote:when I compile this one, it goes mad...

You're going to need to be a bit more specific than that. See ItDoesntWorkIsUseless (<-- click)

Do you get compiler errors?
Does it not do what you expected?
What did you expect it to do?

srikanth darbha wrote:have tried can you please tell me what is that other way

What have you tried? What ideas / approaches did you think might work?

Steve Fahlbusch wrote:read the String object javadocs (very, very carefully)

I think I know where you're going with this. That would work too.

So now thanks to Steve I also have two different ways of doing it. However I don't like one of them because it uses Exception handling for flow control.

Have a read through Oracle's Strings Tutorial paying particular attention to the "Concatenating Strings" section.

See if you can see where you're going wrong.

Didn't you ask the exact same question earlier?

Probably best you follow up in that thread.

Campbell Ritchie wrote:I challenge you to reverse a String without knowing its length. I don't think it is easy without knowing lengths.

Challenge accepted!

I have a solution but I'll hold off and let the OP have a go first.

Edit: If the OP wants to of course

Yes there is.

Any particular reason you don't want to use reverse() or length()? Homework assignment perhaps?

Have you had any ideas yourself on how you'd do this? If so please share and let us know what part you're having trouble with.

Tickets are available: tickets.reactconf.com

When: 7th - 9th April 2014
Where: Shoreditch Works Village Hall, 33 Hoxton Square, N1 6NN

Hyper Reactive - Conference Only
£150
EX. VAT @20.00%

Go Reactive: Hands-On with Play, Akka and Scala - Workshop Only
£398.33
EX. VAT @20.00%

Here's my somewhat simplistic take on writing code with and without tests:

With Tests
"Dear Customer, here's my application that performs to your specification, and here's some evidential proof to back that up. That'll be two million dollars. Thanks"

Without Tests
"Dear Customer, here's my application that performs to your specification, I think, I haven't actually tested it, you'll just have to take my word for it. That'll be two million dollars. Thanks"

A bit tongue-in-cheek I know but essentially that's what you're saying to your customers. Without tests, you're just winging it, and that's not professional.

Readability is very important and should be given the due care and attention it deserves.

It looks to me that you are using debugging as a tool to verify the code's behaviour. You should be using Tests to do this instead. If you had a good test framework with a good test suite then you would use those to tell the story of your code as opposed to expecting future readers of your code to have to debug it manually.

Add these to your imports

Thanks for the Birthday wishes all. Appreciate that.

I got my eBook download link on Monday 20th. Thanks to CodeRanch for putting on the promo and thanks to Simon Brown for hanging out for a week to answer all our (maybe just my) silly questions.

Cheers, Tim

Hello Ron, would you mind please making a new post when replying to a thread rather than updating your existing post. Think of this as a conversation. Going back and changing something you've already said can make the conversation confusing at best, and at worst can make the posts after yours look like nonsense if they're referring to something you said before you edited it.

Thanks

Edit: Ron, Your previous reply came in at the same time as I posted this one. I take it back. You know the score.

Works alright for me when entering doubles. You'll get that error message if you enter something that isn't a double, say like an alpha character.

santhosh kumar vk wrote:then we will go for equals of object class instead of string.equals to check the string object

I don't understand what you mean by this? You don't get to choose.

But yes, Object has an .equals() method, as does String. The are different for good reason. Pretty much all you need to know about the == operator and .equals() method in relation to Strings can be found in this CodeRanch FAQ article

Henry makes an excellent point. Under what circumstances would you ever want or need to do this?

Even as a "java beginner's query" it makes no sense to me. Thread and Runnable are there for the sole purpose of making it easy for you to create concurrent functionality in your application and there is no need to do it any other way.

Let's say you did find some crazy obscure way to do it. If you ever implemented it in a team development environment you would become very unpopular very quickly. Maintenance of that code would be near impossible.

Do you have any idea yourself why this might be?

Hint: Equals is used for comparing instances of things. Think about what it means for two Object instances to be equal, and what it means for two String instances to be equal.

K. Tsang wrote:Yet I doubt file size is an issue.

No. File size is not the issue. Code readability is the issue. When there's lots of unnecessary JavaDoc and Comments it takes a good deal of cognitive load to visually sift the Wheat (code) from the Chaff (redundant comments) which takes away from your ability to think about what code is doing and what you're supposed to be doing with it.

Alexandru Dragoi wrote:and you do not have time to update also the documentation in order to keep up with the code

It's potentially worse than that. Take this example again:

Let's say that the business decides that it's not blue Widgets that are important anymore, it's red ones. The developer comes along and finds that this method is tasked with finding the blue Widgets, thinks "great, all I need to do is change this method to find red Widgets instead". This will almost certainly be the result:

It works! You're happy. QA are happy. The Business Analyst is happy. The customer is happy. Job done. Move on.

But what's wrong with this picture? That's right, the JavaDoc still says it's counting blue Widgets. Now the documentation is lying to you, which is much much worse than having no documentation at all. You might think this JavaDoc neglect is laziness. Maybe it is. But the reality is that this happens all the time.

I'd rather have no JavaDoc than JavaDoc that lies to me.

I understand that this post is in the Certification forum so you're probably more interested in what the Marking Criteria guidelines are for JavaDocs. I cannot help you there.

However, I do tend to take the opposite view of things than K Tsang does. I write as little JavaDoc as possible. Which means with the exception of 'public' API's I mostly write none. I'll back up my viewpoint with some examples:

Example1: Instance variables.

The JavaDoc tells us nothing about the variable that the variable name doesn't. But now my variable declaration takes up 4 times as much space as it needs.

Example2: Field accessors.

The JavaDoc tells us nothing about the method that the method signature doesn't. But now my accessor code occupies over double the amount of space it needs to.

Example3: Methods

In this case you might think that the JavaDoc has value as it describes what the method does. While this is true I don't see it as the positive point you might think. I see that the JavaDoc is covering up the fact that we have a poorly named method that does not reveal its intent with a meaningful name. For this example I would refactor to the following:

Uncle Bob Martin has a whole section in his book Clean Code about JavaDoc, Comments, and naming. Well worth a read.

So for each double you read in with the Scanner you need to keep a record of this in some sort of List structure. Then when you come to print out the results you can include each element in that List in the output.

How do you think you might go about doing that?

You must have some idea of what it's supposed to do right? After all, you were the one who found it on the internet. What were you looking for? What do you think it does? What were you hoping it does?

Just presenting a seemingly random block of code with a "What does this do" tagline is probably not going to get the responses you were hoping for. Please ShowSomeEffort (<-- click)

What tutorial? Please QuoteYourSources (<-- click)

The example you show is pretty silly. Declaring your method to throw some exception that your code will never throw does not make sense. Unless of course "....TODO handle exception" includes explicitly throwing that exception.

Questions:
1: What are you currently using to build your web application?
2: How are you currently managing your application's dependencies?
2: What do you need from Maven that your current setup doesn't give you?

Before we can best help you achieve your goal, we need to understand exactly what your goal is. What is it about Maven that you (think you) need?

Surendra Kumar wrote:Spring is a light-weight framework that works based on a pattern called Inversion of Control or Dependency Injection

True

Surendra Kumar wrote:Here, instead of you creating dependencies between different objects, Spring does it for you.

True. Among other things, but this is it's primary function

Surendra Kumar wrote:So you define different beans/objects in an xml file, and Spring reads this file and creates objects and sets dependencies.

True. Also Spring 2.5+ allows you to use annotations instead of xml.

Surendra Kumar wrote:It just makes your code more readable.

Not necessarily true. The indirection created by managing your dependencies with Spring can be quite difficult to follow unless you have a good IDE with very good Spring integration. Sometimes just using Java is all you would want or even need.

Surendra Kumar wrote:Also faster development time.

Not unless you're well versed in Spring, and even then I'd say it's not always quicker.

Surendra Kumar wrote:Spring also helps testing of your code easier.

Following the Dependency Injection pattern, however you do it, most certainly does make testing easier. I don't think Spring itself makes testing easier. In fact in my experience it often makes it harder, and slower.

Unfortunately without giving us the complete picture it's hard to say what the problem is. On the face of it a NPE could occur in your test method because you may not have initialised rolloverServiceImpl, or pcpId might be null and the method you're testing throws the NPE. But then I see in the stacktrace that you're using PowerMock. Why? Nothing in the test code you've presented requires it.

In order to make things a little clearer you need to do one of two things:
1) If mocks are being used for this test then show us where and how?
2) If mocks are not being used for this test then don't use the PowerMock runner and run the test with just jUnit.

Let us know how you get on.

When comparing two collections of things where the order of the contents is not important the general approach is to order both collections and then compare them. So given that you might think of a String as a collection of characters, how do you think you might go about solving your problem?

Hello Ranchers,

I would like to share some info about a really great sounding 3 day developer conference coming up during early April in London.

http://lanyrd.com/2014/reactconf/

I learned of this event a few weeks ago from one of the organisers and I reckon it's going to be a cracker. It's less of a language and framework love in, and more of an exploration of the design and development techniques required to meet the needs of modern scalable software systems. Full event schedule can be found here.

Tickets are not yet available but I was talking with Martin Thompson last week and he says they're planning to have them available through Lanyrd for the end of January. The organisers assure me that the tickets will be extremely reasonably priced.

Brilliant! What a lovely early Birthday present (birthday tomorrow). Thank you JavaRanch

Sergey Zhylinsky wrote:... Martin Fauler ...

I'm not sure Martin Fowler will thank you for that.

Unfortunately you are unlikely to find anyone here who will just hand over the code for you (NotACodeMill <-- click). However, if you make an attempt at implementing this pattern yourself and come back with any specific problems you encounter then I'm sure you will be very successful with finding some help.

Great responses fella's. Thanks. Another one for the ever growing reading list.

Hi Simon,

Having had your book recommended to me over in this thread about a month ago I was quite pleased to see this little promo pop up this week.

As a developer I tend to approach architecture concerns as an ongoing drive to create clear and intuitive interfaces through TDD and by constantly working to remove duplication through refactorings. On a day to day basis I find that doing these two things, more often than not, results in a pretty well structured design. Applying these techniques on a larger "integration" level context also tends to take care of most architecture type concerns too.

So given that there are a bunch of books already available today that cover a lot of this stuff, such as Refactoring (Fowler), Design Patterns (Gamma et al), Refactoring to Patterns (Kerievsky), Domain Driven Design (Evans), Test Driven Development by Example (Beck), Test Driven (Koskela), to name a few, I would like to know what I might learn from your book that has not already been covered?

I hear you. A pet peeve of mine also. Handy resource to get "normal" land line alternative numbers is http://www.saynoto0870.com/

Congratulations to all. Well deserved I'm sure.