Matthew Bendford

As we had a few threads around that topic lately: Do you use CMD.exe? If so - stop bothering with it and switch to PowerShell.

There're differences between source files and imported classes.

-cp / -classpath only determines where the compiler will search for already existing classes. The source files are usually searched relative from the current working directory (although there's --source(-)path to change that).

For the compiler -cp is meant to point to external classes not relative to the current working directory. As an example I have gathered a rather large list of libraries I often refer to. I placed them in some random folder and set my classpath to point to them. When I now work on a new project I'm in a project-specific folder from where the libraries are not trivial to find relative to the current working directory. In this case I use -cp (or rather my already set classpath) to point the compiler where to find those additional external libraries.

If I want to mess with source files and where there're found and where the generated class files to be placed I could use --sourcepath and -d - but if you go down that far using a build environment like ant, maven or others should be preferred.

In the end it all comes down to understand how packages work, how they relate to their representation within a filesystem or packages as archive and how to determine the actual root.

TLDR: To answer your question: NO, the -cp option does NOT work like an implicit C(W)D (change (working) directory).

@OP
Again - as already mentioned - CMD.exe DOES NOT KNOW unicode/utf-8 - you just CAN NOT set proper utf-8 as codepage - IT DOES NOT WORK!
Please use PowerShell! It's the only option on windows to use proper unicode unless you write your very own CLI.

Why your text file ends up garbage:

String.getBytes("UTF-8");

The problem is that the string you try to read in as UTF-8 IS NOT proper utf-8 and hence the decoding from CHAR to BYTE fails. Have a look what String.toCharArray() gets you and print it like this:
char[] array=input.toCharArray(); for(char c : array) {    System.out.println("%04X", c); }
You will see that what you read in as proper 16bit unsigned chars doesn't match utf-8 but some old dos-era codepage - which could be something like CP855.

TLDR: The root cause of your problem is using CMD and trying to set it to unicode - which isn't supported. M$ never bothered to implement it properly as they introduced powershell with NT6/Vista.

Mostly your quotes aren't ASCII " but those new stylized things like M$ word uses. And the display error is due to CMD.exe is not unicode-capable - try PowerShell.

Mans Usman wrote:why utf-8 not working?

Because even the modern command line interpreter cmd.exe doesn't know utf-8 but only the old codepages back from DOS era. If you want proper unicode support please use PowerShell or build you own using a gui like swing.

Well, I don't dare to declare some of the information here as "wrong" per se - but many can be optimized or are redundant:

1) The point of defining JAVA_HOME is so it can be referenced elsewhere. Why put the entire path to the jdk again in PATH when you already have it in JAVA_HOME? Also: Just the path to JAVA_HOME in PATH doesn't work as PATH require JAVA_HOME\bin instead. So one doesn't put C:\Program Files\Java\jdk-X\bin into PATH but rather %JAVA_HOME%\bin.

2) Be careful when mixing SYSTEM level settings with USER level settings. I'm not quite sure about if there's just addition or override - but usually PATH on the SYSTEM level is so the OS itself works properly. When you have another PATH as USER level this can lead to issue where it may could override the SYSTEM level PATH - which lead to issues when it only contains the path to the jdk bin directory but no longer to system32. So: Either set all on the SYSTEM level and don't bother with the USER level at all - or leave SYSTEM level alone and deal with USER level only!

3) Just using java.exe (or javaw.exe) doesn't work - as this is what windows usually does: "<executable> $1 $*". Try and you will get just an error. To make executable JAR files work it has to be in the form of "<executable> -jar $1 $*". I don't know the way in modern windows as I switched to linux after M$ dropped support for Win7 - but the way you describe will lead to issues as the actual command is not set correct which just leads to a (silenced) error message. That's the famous "nothing happens" (in case of javaw.exe) or "a black window shortly pops up and closes itself" (in case of java.exe).

So, in the end I do have to call out some of what you wrote as "wrong" - simply because it just doesn't work this way. Allow me this question: Have you tried it yourself? I'm not surprised by the upcomming answer.

In the end, for a proper launch it's recommended that java applications ship with a launch script (or something like launch4j) to properly find and start the JVM with the correct parameters. Why? Because windows users are "trained" over decades to just download something from the internet and double-click on it without thinking about how it actually works.

I think you misunderstand how text input works. It's no "key binding" which makes the text appear but rather it's the desktop environment already sending text as input. And how return is handled depends on this: Windows uses CRLF while Linux only uses LF while Mac at one timed only used CR.
You can modify some method - IIRC it's Document.insertText() or something like this - but the question is: WHY do you want to ignore CRLF? Maybe a simple TextField fits your needs better than a TextArea.

Aside from terrible code and not utilizing object orientation I once wrote a multi-player battleships game to be played over network some 10 years or so ago. It was about as terrible as your code - so I guess many go this route on their first attempts.

Although I haven't implemented much lately today I would go a more OOP way using a class for the game itself and an interface for the player which interacts with the game. Using an interface is the catch: You can implement both a human player directly controlling some UI and an AI player which acts directly on the game without the UI.

I would also go a different route about checking for a win condition - only re-do what humans do often isn't a good aproach in computer stuff. Try abstracting what a win is: connection of three fields in a row, column or diagonal. All your duplicate code can be refactored into simpler method just checking a few indexes.

Frank Jacobsen wrote:I use a string buffer, because it is faster to append than to create a new string each time.

As, for some reason, it seem to matter that much to you, here's a quote from the StringBuffer docs:

As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization.

You can use regex on this one: Just define a group with all allowed characters and add a ! as negation to it. Then you can use String.repalceAll() which takes this regex and give a single space as replacement. I'm not sure how "fast" that will be - but mostly less than your 100ms as when it's called 200k times (which is rather trivial btw) it sure gets compiled down to more efficient machine code and is run this way natively - that's the "just in time compilation" part of Java: If the VM sees something executed really often then it gets compiled down to more lower code which can run directly on the host hardware instead of keep interpreting byte code over and over again.
For a dataset of 200k entries I'm sure this will only take a couple of seconds. So 200k a day is like and what's your code doing the other 23h59m30s?
Also: Don'T use StringBuffer - use StringBuilder instead - read docs to learn why.

Well, I gave it second thought and now my question shifts towards: What's the actual information you want to convey?
I can hardly think of any usecase where I would require the value itself as well as the length of its string representation.
As with your other topics to me this sounds like a huge design flaw. Maybe try to phrase the problem you want to solve instead of asking for a solution to a maybe inappropriate way to solve it.

Tan Quang wrote:First, you will not be able to take the length of the integer if you do not convert them into a string.

There're ways to get this without converting an integer to a string.
Question is: Why do you need this and why do you store it as int if the length of its string representation is relevant?

Tan Quang wrote:I want to get that column data but in the form of a string

As I smell a design flaw: Why do you need a value that's stored as integer represented as a String?

Tim Holloway wrote:DE is, I think +44

Close, but not quite. +44 is UK - germany is +49.

Back to topic:

I don't know much about the north american number(ing?) plan (nanp) - but as a german working in customer service for the past decade and thanks to a lot of current and historical information is well documented on wikipedia and other sources I can give you quite some insight in it:

First of all: In germany and I think in most of europe using letters for masking phone numbers is very uncommon. I can't even remember the last time I've seen it and IIRC the full number was written right next to it anyway. I'm not quite sure why from all of europe germany was chose as the example. We don't use it.
What you see way more often is replacing the area code with a short of the town name or, if it has a matching car license plate short, with it. I live in Magdeburg which, as the capital of Sachsen-Anhalt, is its own area. Our local car license plate code is MD. Our phone area code is 0391. So what you often see is like: "MD / 000000" (I used 0s as it's not a valid phone number). Which effective means: "0391 / 000000". That's way more common and works in a lot of areas with big towns as the towns themselfs often have a license plate short which matches the boundaries wherein the phone numbers are organized.

Next - Length of numbers: area codes can be as short as two-/three-digits (like berlin: (0)30) and up to five-/six-digit like (0)39203 (Barleben, a small village right next north to Magdeburg - about as old but refused to join ever since). The leading zero is only required if you don't use international format like +49. So, using +49-0-xxx doesn't work - the 0 has to be omitted.
After you figured out the area code then there's the actual local number. I'm not sure about the minimum - the shortest I've seen is only 4 digits - but they can get quite long. A regular local number is about 7 or 8 digits but can be longer. Mobile is limited to either 7 or 8. They can't be shorter but also can't be longer (at least I haven't seen them any longer than 8 digits after the provider code).

Third: Special sections: For non-mobile numbers they all start with 02x - 09x. 01x is reserved for mobile and payed services. There're however several blocks within the regular scheme: 032xxx - personalized numbers, 0800xxx toll free, 0900xxx payed services (up to several euros per minute) and a few others. There're also numbers starting with 1 - like 110/112 - emergency. Mobile is 015x - 017x but only certain blocks. 019x isn't used anymore but was moved over to 0900.
Up to early 2000s for mobile one could determine the carrier - but since this time port over is supported so you can switch carrier and even the network (currently there're 4 in operation) and can'T rely on the orginal provider codes anymore.

You see: This gets complicated rather quickly. As said: Wikipedia offers great knowledge of current and historical number plans. But I'm not sure if they're availble in other languages, too.
TLDR: At least in germany it's very uncommon to see something like 0800-abcdefg - we're just not used to it and most wouldn't understand to look on the keys on their phone and look at the letters on them. And if someone uses it the regular digits are usually right next to it.