We Keep Coding

Tangible example of Java Container - Specifically in NetBeans

In my search for this answer I have already read the following StackOverflow post.
Definition of a Java Container
My issue (lack of understanding ) at this point as a beginner is also learning the esoteric vocabulary. Therefore, even excellent examples often make little or no sense.
For this question please create an answer for the very, very, green beginner.
The actual question:
For the "Definition of a Java Container" give a tangible example, preferably using the NetBeans project tree, of what a Java Container is. A screen-shot would be very helpful for us extremely visual learners.
For example, if I were trying to answer the question "what is a container file" to a computer 101 student, I would probably not say something like this:"A container or wrapper format is a metafile format whose specification describes how different elements of data and metadata coexist in a computer file.
Rather, I would answer like this: "A container file is a ZIP file, MP3 or MP4 file. The reason it is called a container is that it actually contains many other files - much like a directory."
UPDATE
I found this Wikipedia article that I believe begins a decent explanation.
https://en.wikipedia.org/wiki/Container_%28abstract_data_type%29
For example, according to the above article, a simple example of a "container" in a programming language is an array. In object oriented programming languages fancier arrays such a Lists and Maps are also containers. However, for any beginning programmer reading this post, containers are also Classes that form a chain of inheritance (experts correct my terminology if I am wrong).
For beginners, if you do not know what inheritance is then go study that. There is another Wikipedia article to read.This whole article is describing "containers" in Java.
https://en.wikipedia.org/wiki/Java_collections_framework
To give the sort of example I was originally asking for, if you have NetBeans then go do this:
Create a new class, then inside of it create a new method, as shown below:
package InformationStorage;
public class MyClass {
public void MyMethod(){
}
}
Now, inside the method type the command "System", and then type a period. Like this:
["Screen shot from NetBeans"][3]
Notice the list of methods and other stuff included within "System". If you choose one (for example "out" as in System.out.), then when you type the period after "out" more sub-options appear, and so on.You will eventually end with something like "System.out.println();"
This is an example of Container Classes.

Frustrated-Me this question is posed just like your name haha. Anyway I will answer. There is allot of programming jargon that will not make sense to a beginner, I wouldn't worry about it at beginner stage. So yes there is a container which is the same as say a Collection (List,Map,Set...Array is maybe one too), which just contains other data members.
But then this term is used in another way in Java and other programming languages and frameworks.
What is a container in this sense? Well I guess I would say it's complicated thing that does allot of stuff for you in layman terms. You see, something like programming a website is very complex, and Java as a programming language can be considered verbose by some, this makes for a very difficult time for a developer. So there are all these fancy frameworks, for instance: Spring which may all share some similar concepts such as dependency injection, aspect orientated programming or whatever ever else. Even if you don't know what those things are they are just ways to help the programmer develop a complicated piece of software.
These concepts are often implemented in something that may be called a container. Basically you put your POJO (instances of a java class) in this container, and the container adds functionality to what you have done, via DI, or aspect orientated programing or something else. Usually these containers are built on design patterns such as the proxy or cake or MVC ect.
One might be able to say that a container in this sense does more than just storing your objects/data, but adds additional functionality to make your life easier.

I18n/L10n of an API targeting developers from maximum locales [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am already aware about the best practices for internationalizing/localizing an application so that it is consumable by maximum number of users - from geography, language and locale perspective. My question is - what are the (additional ?) best practices I need to follow if I want to make it easy for developers from across the world to consume my API?
I realize this question is very broad - so I will attempt to reduce the scope: I am particularly interested in creating a REST API and a Java client library for the aforementioned REST API.
Some of the things that come to mind are:
Provide a way for the developer to localize Strings (obvious)
Provide a way for the developer to customize locale-specific artifacts (measurements, units like currency, distance, weights etc)
Internationalize the API documentation (?? - is this done often? Is it practical?)
Beyond these measures, there are other aspects that really confuse me.
Correctness versus Simplicity:
Should I really name my classes to reflect the technical concepts on which they are based? For example, many of the design patterns may make sense to people who are well versed in English, but for developers with a different medium of instruction, they might be difficult to grasp. So, should I, in the interest of simplicity, rename DelegationInterceptor to something using simpler language? I'm wondering whether this simplification might have any (legal ??) consequences ?
Being Culture-Neutral:
Many-a-times, the easiest way for a developer to understand things is to see an example (or even a framework name) that is similar to something they see every day - which is why Pizzeria or Token Rings would be cool as example usages of my API. On the other hand, these same concepts may not be heard of in a country where most of the developers who develop to your API come from. So should I make generic examples? But then, what good are dull, boring, "generic" examples?
It'd be great if anyone could point me to any API's out there which do a good job of catering to developers from varied locales and cultures - not necessarily in the REST or Java space - anything will do.

My 3 cents: i18n best practices are not restricted to "geography, language and locale perspective". I even think that the most interesting aspect of i18n is getting to know and understand different cultures with all their richness.
To answer your question shortly: there is a book on API design written by Krzysztof Cwalina (nice first name, isn't it?) and Brad Abrams called Framework Design Guidelines. There is also some presentation on slideshare.
Anyway, I read the book and I think it is great, eye opening at least.
The longer answer... What you are referring to, is a Programming Usability. I haven't actually seen the topic covered in details (yet), but you can find many articles on Usability of Programming Languages (i.e. these slides). It seems this is pretty new discipline and the one that is pretty hard (it is a mixture of psychology, linguistics, grammar in two different sense, theory behind compilers, algorithmic, ... , and more). The most important would be of course human factor, especially inherent ability to produce errors.
Very interesting topic :)
Going through details of your question:
There is no way to create L10n API, as Localization is a process of adapting the software to local market needs. What you want to create is i18n-related API.
I don't necessary know why it has to be REST API, but to be 100% honest I am afraid that you might want to create some super-fantastic API that is actually against i18n best practices. The first things first: if you want it to be consumed by many developers, it should be regular API just like ICU. Maybe some parts of it could be exposed as RESTful API, but I am not sure why you want to do this.
As I already mentioned, there is something called ICU, especially ICU4J. I know that this API is extremely complex and not very developer-friendly, but it has one very important advantage: it does exist. And it was created by i18n experts, so it really follows best practices. Some parts are inherently complex because of nature of things - they just have to be if you want to implement the cultural support correctly. Sorry.
By the way: I might be wrong, but you said REST API, which rings a bell in my head. I believe you think of i18n support on the client side, don't you? In such case, I must ask one question: what is wrong with Globalize and/or Dojo and why you think it is better option to do everything on the server side?
OK, with Dojo I can answer the question myself: size and responsiveness.
Going through your points: "Provide a way for the developer to localize Strings (obvious)". It is not so obvious. That is, it is not as easy as you might think. If you want to do the obvious, you must be sure to understand the terms: Resource Model, Resource Organization, Locale Fall-back, Message Formatting, Machine Translation and Translation Memory.
Trust me, it is really easy to do a mistake here. On one hand, I doubt that anyone could create an API that will stop regular programmers from being lazy and hardcode strings, I doubt that it will ever happen. On the other hand, your friendly API (if you could achieve this) could easily allow reusing translations (which is i18n defect if it doesn't regard to common things like "OK", "Cancel", etc.). Also, you need to think of formatting capability so that it is (almost) impossible to introduce concatenations (very common i18n defect, preventing correct translations) and at the same time it is easy to handle multiple plural forms (still think you know best practices...?).
Proper organization and valid abstract model might help with implementation of TM and MT (that is reusing of old translations and minimizing the costs of new ones). But this is hard and very few people do it correctly (there are even some frameworks, like Play for example that implement serious misconceptions, i.e. single translation file only).
"Provide a way for the developer to customize locale-specific artifacts (measurements, units like currency, distance, weights etc)". Great idea. But please make sure that you will include formats as well. I mean that number format varies, unit varies, unit name and symbols (even for the same units) varies, but also unit placement may vary.
Some of these artifacts are already in ICU and CLDR, but for others you would actually need to get valid translations of patterns and items themselves.
From my experience it might be hard to collect the translations in the first place, yet valid ones...
"Internationalize the API documentation". Let me guess: you meant Localize, which in that case would probably be equal to Translate.
To be honest, I don't think that translating documentation of some API or Framework is all that important. Professional programmers have to have some command of English, at least be able to understand the technical documentation and write passable code (in terms of variable names and comments) - it is very unprofessional not to use English for such items.
"Correctness vs. Simplicity". I am not sure what kind of correctness you refer to. In terms of English language grammar, I would definitely favor simplicity over language correctness.
In terms of valid support for i18n, there are so many incorrect libraries already, please refrain from providing another one. As I wrote before, some things are inherently complex and they could be either done correctly (that will result in a complex API) or should not be done at all. Bringing simple, but only partially correct solution for cultural support will result in large number of defects (that I will curse you for) and the need to find even more complex workarounds. It is not worth the effort.
"Being culture neutral". Please read the book, I recommended. It covers this shortly (there is no need to go deeper, actually).
I doubt you should actually strive so much for political correctness, just avoid something you are sure my hurt somebody's feelings (don't do to others what you don't want to do unto you). That's it.
EDIT: Just two more things.
It might be a good idea to actually perform Usability tests on your API (just like you would do for User Interface). If it feels natural and intuitive, you did a great job. By doing that, you will also learn how people might want to use your library, that is you will discover additional use cases.
It is probably much harder to create programming library than to actually create a program. In case of library/API you often need to break truths that are (or at least seem to be) carved into stone, that is create something that is against common OOP/OOD principles, but is easy to use. You would also need to provide more overloads (there are many different use cases, mind you). Something as simple as formatting Date/Time in Java could really give you a headache if you want to support java.util.Date, Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp, XMLGregorianCalendar, Joda Time and JSR-310.
As a side not, I am not sure if sending formatted date/times over REST API is actually the i18n best practice...

Groovy Migration for Java Developer [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've been a Java developer for several years now. Lately there's been quite the buzz over Groovy. I checked it out and it looks interesting and all, but I'm not seeing any inherent "wow factor" to it; meaning, I'm not seeing any intrinsic value to begin developing in it.
Now, I'm positive that I'm just not seeing the forest through the trees here. So, I ask the SO community at large: how would learning Groovy behoove any Java developer? What features/capabilities/etc. does it do (or do better) than plain ole' Java?
Things in the software world don't take off like wildfire without a reason. I'm sure Groovy has all sorts of nifty little (and big) capabilities that make it a must-know; I'm just not "getting" it. Thanks in advance.

In my opinion, some of the biggest adventages Groovy has over Java are:
terser code thanks to overloaded operators and simplified property access. Instead of writing
if (obj1.getBar().equals(obj2.getBaz())) {
obj3.setFoo("equal");
}
you can write
if (obj1.bar == obj2.baz) {
obj3.foo = "equal"
}
which I consider much more readable.
inline notation for Maps and Lists. Instead of
Map attributes = new HashMap();
attributes.put("color", "red");
attributes.put("width", 1);
you can write
def attributes = [color: "red", width: 1]
useful extensions to standard libraries. For example, you can read files and webpages like this:
def fileContents = new File('readme.txt').text
def pageContents = new URL('readme.txt').text
syntactic sugar for initializing properties - for example,
MyClass myObject = new MyClass();
myObject.setFoo("bar");
myObject.setBaz(23);
can be replaced by
def myObject = new MyClass(foo: "bar", baz: 23)
'safe' dereferencing - if (str != null) {return str.toUppercase();} else {return null;} becomes return str?.toUppercase()
Regular Expressions look nicer
Closures allow you to write code in 'functional' style, and make writing things like event listeners way easier

... since no one pitched in so far, I'd suggest looking at the Grooy mailing list. Similar questions pop up from time to time regarding Grails as well. Those are great communities of people who at some point or another faced the same type of questions.

I'll add another, since I don't see it explicitly mentioned.
For me, while terseness is nice on its own, it isn't the main point.
Whatever code you write, Java will always look like Java, and it will never read like the problem you're solving--it will read like Java, solving your problem.
I want the reverse: I want my code to read like the problem I'm solving, written in [insert language here].
Groovy is more expressive, more malleable than Java. It can look like what I'm trying to do. Canonical examples of this include internal DSLs. One I've used frequently is easyb, which is just Groovy code, but sounds like what I'm doing when I read it out loud. There are a bunch more examples, but easyb is an easy sell.
Also not mentioned are the AST transformations allowing cool compile-time tricks. You can play similar games in Java with things like AspectJ, but it's not as "baked in". Things like #Delegate, #Singleton, etc. are just plain handy.
For me, a language needs to be malleable, deformable, flexible: Java is not. Java has an impoverished model of abstraction making it frustrating to work with--the amount of extra work, writ both small and large throughout the language, is mind-boggling at times.

You're kinda late to the party. Groovy saw its dawn about 4 years ago when people fed up with Java's ridiculous verboseness were ready to give up performance in the sake of code reduction and Groovy was providing them with exactly that in a very familiar syntax. But now that it's been there for a while it gets dragged by its past as much as every language does and some not best design decisions are there to stay as much as I'm pretty sure are its performance issues. This basically was the reason of emergence of Groovy++, the whole existance of which suggests that there are some problems with its predecessor. And in fact Groovy++ addresses a lot of issues of its predecessor, but it also has its own problems: the main one being that it's basically driven only by the devotion of a one man - Alex Tkachman that is, - and no funding, so you should see all the risks involved.
Nowadays that more and more strong rivals appear (Kotlin, Ceylon) it becomes obvious to me that Groovy has already passed even its zenith - even its core team is trembling (you should see their discussions on Grumpy mode). This was the reason for me to start gradually leaving this technology in preference to Scala and to look forward to forthcoming Kotlin which both are great projects but take some effort for a "Java mind" to switch to, but are definitely worth it.
Updates due to hypercritical response:
Design mistakes:
Restricting syntax for Java paste-in compatibility, while a seemingly neat feature in practice turned out to be not used at all, 'cuz migrating Java code to Groovy is generally a bad idea for the same performance reasons. But this resulted in inheritance of some Java's ridiculousness like not being able to define a variable of the name used in the outer context
While keeping some of Java's bad practices they got rid of some of its good features too, like code blocks demarked with curly braces in preference to closures. The issue solved much neater in Scala
Dynamic typing was mainly chosen because decent type inferring was hard to realize - that was basically the reason for Groovy's creator to later state that he would have never bothered creating it if he knew about Scala back then.
Googling for "groovy performance" will give you enough results. Here is one: http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html
I never stated that Groovy++ is the same project as core Groovy.
I would like you to know that I once was a huge fan of Groovy and was developing in it exclusively for 2 straight years. Moving on to a new language was a very hard step for me to take. But since I know Groovy's every corner, I know its core team and its tendencies you should understand that I know what I'm doing when I'm recommending not to consider Groovy as an alternative to Java.

Is it compulsory to learn about Data Structures if you want to be a Java/C++ programmer? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So do I really need to learn about them ? Isn't there an interesting way to learn about stacks, linked lists, heaps, etc ? I found it a boring subject.
**While posting this question it showed some warning. Am I not allowed to post such a question ? Admins please clarify and I will delete it :/
Warning :: The question you're asking appears subjective and is likely to be closed.
okay..I get it
So what is THE best way to learn them ? What book do I refer ? What website ?

It's compulsory to learn about data structures if you want to be a programmer. Data structures are your bread-and-butter - if you don't understand things like the behavior, uses, and run-time complexity ('big-O') of at least the basic structures (arrays, linked lists, stacks, queues, trees (binary / n-ary, self-balancing varietes), hash-tables, heaps, graphs) and the algorithms that run on them (insert / locate / delete), you won't know which is appropriate to use under what circumstances.
Every trade has its tools; these are ours. Data structures are the most basic underpinnings of almost any algorithm that you're going to learn. Unless you want to be a cargo cult programmer, you need to understand how they work.
Whether or not there are interesting ways to learn about them is a separate question entirely... :)

I would go even so far as to say that most of programming revolves around manipulating data structures, it is the foundation of computing after all: you get some data, you process it, you possibly give output. All the data usually reside in data structures and choosing inappropriate structures will have the bigger impact the bigger the project.

As you get more experience you will find that algorithms and datastructures are invaluable to your day-to-day development, and actually pretty interesting.
By learning about them now you will learn:
Which data structure is appropriate for which context, i.e. when to use a single-linked list, when to use a stack, when to use a queue, when to use a tree
Which algorithms are appropriate for which purpose, such as tree depth-first search or breadth-first search.
Space and time complexity of algorithms, for example why is a quicksort sometimes the best solution, and sometimes heapsort.
Overall it'll teach you the beginnings and fundamentals of computer science, even if you never have to implement a stack again you'll know the kind of thought and consideration that goes into it. If you then ever have to implement your OWN data structure (and chances are you will, quite often), you will know what to do and what not to do.

If you want to be a successful programmer, data structure is a must. How will you program if you don't know data structures and algorithms?

Whether you like it or not, all programming is built around data structures. You may never have to write one, but you will have to choose which one to use many times. It is not really a requirement to programming in general, but if you want to excel in the field, understanding of the basics is a must.
Anyone can build a shed without knowledge of materials or construction techniques. You can even work in a house placing bricks and mortar under the orders of someone else, but if you want to build a house yourself, you do need to understand materials and techniques.
Data structures are the programming materials. Algorithms are techniques. Will you use data structures? You will use the simplest ones in a daily basis, each so often you will need to solve a problem where an specific data structure is required, and while you may manage not to build your own bricks, you will need to understand whether you need bricks or a concrete wall for your purposes.

If you want some evidence for the importance of data structures, take a look at the Google hiring process. Whatever you think about Google as a company, there is no denying that they have some very good people working for them. Their interview process is setup to determine the candidates knowledge of data structures and algorithms. Because when it comes down to it, that is what is at the core of programming, no matter what language you are working in or what domain you are programming for.
If you are planning a career as a professional programmer, you need to know the fundamentals, not just how to crank out code that "works". Otherwise, your just playing.

Is it compulsory to learn about arithmetic to be an engineer?

If you take the attitude of "is it compulsory" with regards to any of the building blocks of programming languages, you're probably not cut out to be a coder. Regardless of "compulsory" or not, you should always be looking for new concepts to learn and seeing if it'll improve your coding style/standard.
But in answer to your question: yes.

I'd say it's compulsory at some point in your development to have a firm grasp. I'm not necessarily sure the standard Data Structures course is the best way to learn. Sometimes, the best way to learn them is "I have problem X. For some reason, it's taking my algorithm a long time to solve X. How can I make this faster?"
One book I'd highly recommend is Programming Pearls. It has some really good analyses, backed by a lot of examples of where the real-world motivations for the solutions came from. It presents the problems in an interesting manner, and never teaches by giving you a laundry list of data structures.

Yes 99% of books on Data Structures are boring and exercises contrived. They feel like they are just making up problems that server no practical purpose :(
This book is the one exception to the rule I've come across. You will have a naive but working RPG game by the end of the book:
Data Structures for Game Programmers
Read the above book and you will solve your chicken and egg problem and see you really can't do much without data structures after all.

Well, this may sound a little awkward but I wouldn't say it is COMPULSORY to learn Data Structures to be a - regular- developer. Seriously! Of courser if you study then hard it will give you a lot of insights and knowledge on several programming aspects and that's always good. But compulsory ... well, I think it is just too much. VERY GOOD would be enough.
Let me explain why. It is not that often, for today, to write Data Structures code because - let's face it - it would be RE-writing, RE-inventing what we already know for so many years! What I would say it is COMPULSORY is to study just the general theory of them and the APIs/libraries that are already commonly in use (and tested and optimized) like the Collections API in Java. You must know by heart the differences between a List and a Set (in Java for instance) and their capabilities and proper usage but you don't need to know exactly HOW they are implemented - checking every private method and attribute - to deal with most common, day to day, coding problems. You will do just fine without all the "guts" of Data Structures for the general stuff. We face different challenges now.
But don't get me wrong - neither think I am crazy or naive! Off course there are situations that you will need to implement yourself some sort of custom data structure (maybe your own BalancedBinaryTreeMap!). You got to be prepared for everything.
I am just arguing about being compulsory or not. Again, I don't think is compulsory but it is indeed very good.
Cheers.

I suppose you could learn programming without learning a whole lot about data structures or algorithms. To make an equivalent example, think of it like if a carpenter knew how to build things, but didn't know about measurements and such. Would he be able to get a career in carpentry? Possibly, but let's say he needed to know the exact material he would need to complete a project. He'd probably get fired because he doesn't know what sort of material or measurements to use.
So with data structures and algorithms, you can say it's the ability to give exact measurements of an application and knowing what sort of performance you'll get out it.

Like a musician learning scales, data structures are part of the tools of the software trade. Sure you can work as a programmer without the knowledge but you're handicapping yourself. If I'm interviewing two people for a position and one of them understands and uses structures and the other can't even explain what a stack is, my choice is pretty clear.
If you want to be judged to be a competent, employable programmer, you need to learn your craft.

Is it compulsory to learn them?
No, you can program without them, just as it's not compulsory to break your code into functions.
That being said, if you want to be an effective programmer that can write at least decent code without getting your car egged by your coworkers, you want to at least be able to make a decent selection of library classes.
Every programmer should understand the tradeoff between a LinkedList and an Array, or why binary searches and binary trees are useful for sorted data. This isn't just about performance - it's about correctness too since you can't just put anything into a tree set.
Does it mean that you need to know how to implement your own AVL tree, build super-smart data structures, etc.? Not necessarily. It's a matter of how much you want to know what's going on "beneath the hood" and whether your tasks necessitate it.
I'm not a big fan of deep data structure and algorithms questions in interviews because the vast majority of developers don't need to implement these things, just to use library stuff. I prefer to ask job related questions in interviews. However, accept that if you don't learn those things you would face a tougher battle to get other jobs.

It should be, yes...

No body should force you to learn anything you don't want to learn.
If you're the type of person that is compelled to be the best that he/she can be at what he/she does, and you love what you do for a living, you'll learn everything there is to know on your own accord.
#happysoul: You should ask yourself WHY learning data structures bore you. Also, it would help if you also identify what DOESN'T bore you.
If you at least love to learn about algorithms, I'm sure we can all suggest a perfect marriage of the two that would be exciting to learn!
My recommendation for best algorithm/data structure combo for the most fun learning experience: graphs.

How to revise java? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Ok so this isn't 100% programming question, for which I'm really sorry, but still this is the best place I know to ask it.
In ~2weeks time I'll have a job interview, first they'll make me take a test from Java and I was wondering what's the best way to prepare for it? I bet it will be something similar to SCJP (but probably much easier), are there any (short) books, tutorials that are worth reading? I did order the SCJP book by Sierra/Bates but I won't be able to read it before the test.
Don't get me wrong I do have experience with Java etc. but I really want to get the job so I want to go there well prepared.
Also marry Xmas to everyone, no matter what religion you are.

Don't get me wrong I do have
experience with Java etc. but I really
want to get the job so I want to go
there well prepared.
If you have enough experience don't worry about the test. Don't try to impress your next boss with an awesome test that does not reflect your current knowledge. Read Joel's posts about interviewing:
The second worst kind of interviewer
is the Quiz Show Interviewer. This is
the kind of person who thinks that
smart means “knows a lot of facts.”
They just ask a bunch of trivia
questions about programming and give
points for correct answers. Just for
fun, here is the worst interview
question on Earth: “What’s the
difference between varchar and
varchar2 in Oracle 8i?” This is a
terrible question. There is no
possible, imaginable correlation
between people that know that
particular piece of trivia and people
that you want to hire. Who cares what
the difference is? You can find out
online in about fifteen seconds!
Remember, smart does not mean “knows
the answer to trivia questions.”
Anyway, software teams want to hire
people with aptitude, not a particular
skill set. Any skill set that people
can bring to the job will be
technologically obsolete in a couple
of years, anyway, so it’s better to
hire people that are going to be able
to learn any new technology rather
than people who happen to know how to
make JDBC talk to a MySQL database
right this minute.
quoted from "The Guerrilla Guide to Interviewing (version 3.0)" by Joel Spolsky
If you need to impress someone to get the job, may be that's not a good place to work...

I recommend you pick up Effective Java, 2nd Edition by Joshua Bloch and read it cover to cover. It details several "best practices" for Java and will have you walking into the interview knowing for example things like:
when to use Static Factory Methods
when to use the Builder Pattern
what a Singleton is and how to enforce it
how to prevent instantiation of a class
why to avoid finalizers
the general contract for overriding equals and hashcode
to use accessor methods instead of public fields
to prefer lists to arrays
to favor generic types
to use enums instead of int constants
to return empty collections or arrays instead of null
to prefer for-each loops over traditional for loops
to avoid float and double if exact values are needed
beware of performance loss when doing string concatenation
refer to objects by their interfaces
Not to mention the other 40 or so topics that I can't remember off the top of my head. If you're able to talk about these topics and demonstrate an understanding, then there's no reason you shouldn't be in the running for the position since learning this material will already put you in the top 10 percentile of Java developers.

I have a little book with "Exam Cram" in its title. The emphasis is on "little;" you can read through it in a single evening. It describes in prose all the important features of Java, it contains tables of quick facts that will be essential, and it covers, briefly, all of the SCJP exam.
For the less than eidetic, it gives hints on how to write yourself a crib sheet from memory once the test starts (meaning you can carry a bit of what you need to know in short-term memory). There are also some tips on pitfalls and such. Finally, and perhaps most importantly, there is at least one practice exam in it (haven't looked at it in a while) and a bunch of drill questions.
Alas, from what I see at Amazon, the book I recommended only covers Java 2: http://www.amazon.com/Java-Exam-Cram-310-025/dp/1576102912 Still, there are bound to be similar, more timely books.
This one: http://www.amazon.com/SCJP-Certified-Programmer-Java-310-065/dp/0071591060/ref=sr_1_1?ie=UTF8&s=books&qid=1261601183&sr=1-1 by Kathy Sierra is similar and about Java 6.
Some people would (and in fact did) recommend buying a general purpose Java book. Ideally, all you should have to do is learn "all of Java" and then you'd be ready for the exam. But this is not a winning strategy!
related anecdote
The first time I took my driver's test with the DMV, I had a long wait and quickly skimmed through a little info booklet they provided. I easily scored 100.
I later had to take the test again. Knowing the test was laughably easy, I spurned the booklet and failed the theoretical test. The booklet didn't contain anything I didn't already know: But being by the same people who administer the test, it contained the same wording, it had similar situations from the test, it emphasized similar topics and situations. In a few minutes, it could easily make the difference between passing and failing.
Conclusion
Same approach with these "prepare for test XXX" books. It's a racket, but the special-purpose prep books work better at preparing you for the test than general knowledge (or general knowledge books) do.

May be you should read Eckel's Thinking in Java. In this book many specific java features are considered.

I would rather prepare my self to explain what I already know about java and how much I would like to work for that company.
While the programming knowledge is essential, I don't think you can improve much further in two weeks.
Better would be for you to prepare to answer, why do you want to work there, why should they hire you. etc.

My recommendation is HeadFirst Java to brush up on anything you may have some issues on. The SCJP is something that they may make you take upon hiring within 6 months for example, however I have never heard of a company making someone take a proctored test at an interview. Hope this helps.

Write something small but useful in Java, in whatever environment they're going to be using (applets, JSP, desktop...). That way you won't freeze trying to remember how to do e.g. console output.

If possible, show them some Java code you've obviously written and that you're proud of.

Brush up or learn the following :
Simple concepts e.g. static keyword, importance of equals and hashCode, etc.
How generics in java work?
How threading works, deadlock, race conditions, etc.
How java deals with memory. Can garbage collection be enforced?
Basics of OOP.
Basics of String, StringBuffer, StringBuilder, RuntimeException, etc.
Design patterns, e.g. singleton, visitor, etc.

If you want to know the language well then The Really Big Index will be invaluable. It's a huge list and you'd struggle to read it straight though but for a reference it's fantastic. Read it along with a set book like Thinking in Java or the SCJP book you've already ordered and you'll be absolutely fine.