By Reg

2015-06-09 09:02:16 8 Comments

The following code produces the output "Hello World!" (no really, try it).

public static void main(String... args) {

   // The comment below is not a typo.
   // \u000d System.out.println("Hello World!");

The reason for this is that the Java compiler parses the Unicode character \u000d as a new line and gets transformed into:

public static void main(String... args) {

   // The comment below is not a typo.
   System.out.println("Hello World!");

Thus resulting into a comment being "executed".

Since this can be used to "hide" malicious code or whatever an evil programmer can conceive, why is it allowed in comments?

Why is this allowed by the Java specification?


@Arp 2017-11-02 13:01:16

The compiler not only translates Unicode escapes into the characters they represent before it parses a program into tokens, but it does so before discarding comments and white space.

This program contains a single Unicode escape (\u000d), located in its sole comment. As the comment tells you, this escape represents the linefeed character, and the compiler duly translates it before discarding the comment.

This is platform-dependent. On certain platforms, such as UNIX, it will work; on others, such as Windows, it won’t. Although the output may look the same to the naked eye, it could easily cause problems if it were saved in a file or piped to another program for subsequent processing.

@mmgross 2018-01-02 11:10:07

As eloquent as your "answer" might be, it actually is not an answer at all. OP's question was "Why is this allowed" but this here is an explanation of how it works...which OP already provided.

@Clearer 2018-02-07 12:48:25

Do you have any sources to confirm that this is platform dependent? If this is true, I would consider Java to be entirely broken (I do anyway, this is just another nail in the coffin).

@david 2019-01-21 20:15:38

The Java compiler treats a bare \u000d as ending a single-line // comment, even on Windows. (Tested with Oracle Java 1.7 and IBM Java 1.8 on Windows 7, just to be sure...)

@aioobe 2015-06-09 09:13:50

Unicode decoding takes place before any other lexical translation. The key benefit of this is that it makes it trivial to go back and forth between ASCII and any other encoding. You don't even need to figure out where comments begin and end!

As stated in JLS Section 3.3 this allows any ASCII based tool to process the source files:

[...] The Java programming language specifies a standard way of transforming a program written in Unicode into ASCII that changes a program into a form that can be processed by ASCII-based tools. [...]

This gives a fundamental guarantee for platform independence (independence of supported character sets) which has always been a key goal for the Java platform.

Being able to write any Unicode character anywhere in the file is a neat feature, and especially important in comments, when documenting code in non-latin languages. The fact that it can interfere with the semantics in such subtle ways is just an (unfortunate) side-effect.

There are many gotchas on this theme and Java Puzzlers by Joshua Bloch and Neal Gafter included the following variant:

Is this a legal Java program? If so, what does it print?


(This program turns out to be a plain "Hello World" program.)

In the solution to the puzzler, they point out the following:

More seriously, this puzzle serves to reinforce the lessons of the previous three: Unicode escapes are essential when you need to insert characters that can’t be represented in any other way into your program. Avoid them in all other cases.

Source: Java: Executing code in comments?!

@Bathsheba 2015-06-09 09:15:27

In short then, Java intentionally allows it: the "bug" is in the OP's IDE?

@Aaron Digulla 2015-06-09 09:17:19

@Bathsheba: It's more in the heads of people. People don't try to understand how Java parsing works, so IDEs sometimes display the code in a wrong way. In the example above, the comment should end with \u000d and the part after it should have code highlights.

@Aaron Digulla 2015-06-09 09:18:40

Another common mistake is to paste Windows paths in the code like // C:\user\... which leads to a compile error since \user isn't a valid Unicode escape sequence.

@Reg 2015-06-09 09:19:32

I understand introduction of unicode characters, but not so much why it is allowed in comments?

@bluelDe 2015-06-09 09:21:31

In eclipse the Code after \u000d is highlighted partially. After pressing Ctrl+Shift+F the character is replaced with new line and rest of line is wrapped

@TheLostMind 2015-06-09 09:22:12

So.. this is related to how the compiler parses the source-code file?. This problem can't be reproduced when we use block comments instead of single line comments

@aioobe 2015-06-09 09:22:25

@Reg, there are many features of the language that doesn't make sense in conjunction with other features of the language. In this case, the language designers put the unicode escape handling before the parser, and being able to use unicode escapes in commens was simply a (possibly unfortunate) side effect.

@Gregor Raýman 2015-06-09 09:27:03

While I agree with the answer from @aioobe that the source code is valid and the problem is rather in the IDE (and the source code highlighter on StackOverflow), please note that there is another "problem" with the code. The CR character entered as unicode escape sequence is interpreted as a correct start of a new line, but the line number is not incremented.

@aioobe 2015-06-09 09:31:52

@UmaKanth, // comments are skipped all the way to the next new-line character. \u000d is interpreted as a new-line character.

@Taemyr 2015-06-09 11:27:43

@TheLostMind If I understand the answer correctly you should be able to reproduce this with block comments as well. \u002A/ should end the comment.

@Dorus 2015-06-09 18:23:39

@Taemyr wow, \u002A/ is really evil, eclipse utterly fails to parse it. Put code between /*\u002A/ and /\u002a*/ and it's completely hidden as comment. Found this as bug 3533

@R.. 2015-06-12 22:47:52

Note that this could have been avoided completely if the language specification had forbidden using \u notation to represent anything representable in ASCII.

@Ben 2015-06-13 18:23:40

@r good point, well made. At the very least this should be a Level 1 Compiler Warning.

@Mooing Duck 2015-06-13 21:58:19

@R..: That would make it so that if you're developing on a computer that doesn't use ASCII, then there are many characters you can't type in, such as IBM Mainframes that use EBCDIC, which doesn't have curly braces.

@R.. 2015-06-13 22:01:16

@TBohne: Do you actually have in mind such a character?

@Mooing Duck 2015-06-14 01:43:48

@R..: Yes, curly braces. {}

@R.. 2015-06-14 02:20:09

@TBohne: Wikipedia claims they're at positions C0 and D0 in EBCDIC. It seems pretty ridiculous to expect programmers to use \u escapes for something as ubiquitous as braces...

@Mooing Duck 2015-06-14 15:54:52

@R.: A quick glance shows you're right. But it also contains "Portability is hindered by a lack of many symbols commonly used in programming and in network communications, such as the curly braces." and "It exists in at least six mutually incompatible versions". I assume it must be a different version.

@supercat 2015-09-27 19:47:30

@R..: One wouldn't have to forbid everything in ASCII if one were to specify that the first pass of compilation is subdivision into lines, and any new-line characters that get introduced after that will be processed as-is, such that string st="Hello\u000D\u000Athere" would generate a twelve-character string containing a carriage return and a new-line.

@Jean-François Savard 2015-10-07 17:17:56

If ever anyone is skeptic and want to test the hello world program, the class should be named "". There is other funny thing that may be caused by this... For example, insert LRM character will allow you to compile code such as for (char c‮ = 1; c‮ > 0; c‮++)

@Jean-François Savard 2015-10-15 14:12:30

@biziclop Can we call it comment of the day even if it was posted 8 days ago ? :/

@Martijn 2015-06-12 11:59:23

The only people who can answer why Unicode escapes were implemented as they were are the people who wrote the specification.

A plausible reason for this is that there was the desire to allow the entire BMP as possible characters of Java source code. This presents a problem though:

  • You want to be able to use any BMP character.
  • You want to be able to input any BMP charater reasonably easy. A way to do this is with Unicode escapes.
  • You want to keep the lexical specification easy for humans to read and write, and reasonably easy to implement as well.

This is incredibly difficult when Unicode escapes enter the fray: it creates a whole load of new lexer rules.

The easy way out is to do lexing in two steps: first search and replace all Unicode escapes with the character it represents, and then parse the resulting document as if Unicode escapes don't exist.

The upside to this is that it's easy to specify, so it makes the specification simpler, and it's easy to implement.

The downside is, well, your example.

@ninjalj 2015-06-13 12:33:46

Or, restrict the use of \uxxxx to identifiers, string literals, and character constants. Which is what C11 does.

@Martijn 2015-06-13 16:11:03

that really complicates the parser rules though, because those are what define those things, which is what I'm speculating is part of the reason it is the way it is.

@Holger 2015-06-09 17:59:10

Since this hasn’t addressed yet, here an explanation, why the translation of Unicode escapes happens before any other source code processing:

The idea behind it was that it allows lossless translations of Java source code between different character encodings. Today, there is widespread Unicode support, and this doesn’t look like a problem, but back then it wasn’t easy for a developer from a western country to receive some source code from his Asian colleague containing Asian characters, make some changes (including compiling and testing it) and sending the result back, all without damaging something.

So, Java source code can be written in any encoding and allows a wide range of characters within identifiers, character and String literals and comments. Then, in order to transfer it losslessly, all characters not supported by the target encoding are replaced by their Unicode escapes.

This is a reversible process and the interesting point is that the translation can be done by a tool which doesn’t need to know anything about the Java source code syntax as the translation rule is not dependent on it. This works as the translation to their actual Unicode characters inside the compiler happens independently to the Java source code syntax as well. It implies that you can perform an arbitrary number of translation steps in both directions without ever changing the meaning of the source code.

This is the reason for another weird feature which hasn’t even mentioned: the \uuuuuuxxxx syntax:

When a translation tool is escaping characters and encounters a sequence that is already an escaped sequence, it should insert an additional u into the sequence, converting \ucafe to \uucafe. The meaning doesn’t change, but when converting into the other direction, the tool should just remove one u and replace only sequences containing a single u by their Unicode characters. That way, even Unicode escapes are retained in their original form when converting back and forth. I guess, no-one ever used that feature…

@ninjalj 2015-06-09 18:17:30

Interestingly, native2ascii doesn't seem to use the \uu...xxxx syntax,

@Holger 2015-06-09 18:52:23

Yeah, native2ascii was intended to help preparing resource bundles by converting them to iso-latin-1 as Properties.load was fixed to read latin-1 only. And there, the rules are different, no \uuu… syntax and no early processing stage. In property files, property=multi\u000aline is indeed the same as property=multi\nline. (Contradicting to the phrase “using Unicode escapes as defined in section 3.3 of The Java™ Language Specification” of the documentation)

@zwol 2015-06-09 19:28:50

Note that this design goal could have been achieved without any of the warts; the easiest way would have been to forbid \u escapes to generate characters in the U+0000–007F range. (All such characters can be represented natively by all the national encodings that were relevant in the 1990s—well, maybe except some of the control characters, but you don't need those to write Java anyway.)

@Holger 2015-06-09 19:34:37

@zwol: well, if you exclude control characters which aren’t allowed within Java source code anyway, you are right. Nevertheless, it would imply making rules more complicated. And today, it’s too late to discuss the decision…

@David 天宇 Wong 2015-06-17 21:21:43

ah the problem of saving a document in utf8 and not latin or something else. All my databases were broken as well because of this western nonsense

@ZhongYu 2015-06-09 16:47:46

I agree with @zwol that this is a design mistake; but I'm even more critical of it.

\u escape is useful in string and char literals; and that's the only place that it should exist. It should be handled the same way as other escapes like \n; and "\u000A" should mean exactly "\n".

There is absolutely no point of having \uxxxx in comments - nobody can read that.

Similarly, there's no point of using \uxxxx in other part of the program. The only exception is probably in public APIs that are coerced to contain some non-ascii chars - what's the last time we've seen that?

The designers had their reasons in 1995, but 20 years later, this appears to be a wrong choice.

(question to readers - why does this question keep getting new votes? is this question linked from somewhere popular?)

@Holger 2015-06-09 17:25:00

I guess, you are not hanging around, where non-ASCII characters are used in APIs. There are people using it (not me), e.g. in Asian countries. And when you are using non-ASCII characters in identifiers, forbidding them in documentation comments makes little sense. Nevertheless, allowing them inside a token and allowing them to change the meaning or boundary of a token are different things.

@ZhongYu 2015-06-09 17:29:39

they can use proper file encoding. why write int \u5431 when you can do int 整

@Holger 2015-06-09 17:34:31

What will you do when you have to compile code against their API and cannot use the proper encoding (assume that there wasn’t widespread UTF-8 support in 1995). You just have to call one method and don’t want to install the Asian language support pack of your operating system (remember, the nineties) for that single method…

@ZhongYu 2015-06-09 17:37:36

Is that an imaginary scenario? I don't think it happens in real world.

@Holger 2015-06-09 18:09:14

It would be even worse if arbitrary characters were allowed in identifiers but at the same time, accessing these identifiers from certain locales were impossible. When you design a language, you should decide. I can live with a language restricting symbols to ASCII as I see the problems with localized source code. But I’m also an active user of the all-English stackoverflow site, so I (and probably you as well) have a bias. We know the worth of being able to talk with others (on an international site) about the code. By the way, I left an answer explaining the original intent (afair)…

@ZhongYu 2015-06-09 18:16:42

What is much clearer now than 1995 is that you better know English if you want to program. Programming is an international interaction, and almost all resources are in English.

@ninjalj 2015-06-09 18:20:59

@Holger: non-ASCII in identifiers is another can of worms, since it is not only non-ASCII alphanumeric, but it includes too much, including control codes:…

@Holger 2015-06-09 18:24:02

I don’t think that this has changed. Java’s documentation was all-English most of the time as well. There was a Japanese translation maintained for a while but maintaining two languages doesn’t really back up the idea of maintaining it for all the locales of the world (it rather disproved it). And before that, there was no mainstream language with Unicode support in identifiers anyway. So I would guess, somebody thought that localized source code was the next big thing. I would say thankfully, it didn’t take off.

@Holger 2015-06-09 18:29:41

@ninjalj: yeah, I like what you can do with embedded right-to-left writing but also things as simple as the fact that and ä are different identifiers (because one is U+0061U+0308 and the other U+00E4).

@ninjalj 2015-06-09 18:36:12

@Holger: RTL itself can also be confusing. There was a question which I cannot find right now where the OP was trying to match a substring on a string: the arguments were reversed.

@ZhongYu 2015-06-10 17:48:00

@StephenP - you are probably thinking %n in format(). \n means exactly the character 0x0a, see‌​0.6

@anonymous 2015-06-10 21:18:46 I feel that unicode could be valid in a comment... more specifically a documenting comment /** ... */ with a description that will be generated into an HTML javadoc page; now in that case I'd probably still use a literal newline over this, and for a documenting comment, it wouldn't suffer this issue unless I had the unicode characters for BOTH * and / in the comment directly after one another because documenting comments are not terminated by a single new line character.

@ZhongYu 2015-06-10 22:41:32

@anonymous - good point. however we can use xml escaping there - ⪹ -> ⪹

@Haakon Løtveit 2016-02-28 08:24:10 What am I supposed to do when I have to model something that doesn't have an English name? This is pretty common if you ever deal with domains like law or business or similar that lack these things. Especially in legal domains, words have very specific meanings. Imagine if the standard alphabet didn't have C, X or Q. Now you have a class called "KommonLaw" or something. You'd want to use the 'C'. In your world, that's wrong. But what if KommonLaw meant something else. Now what? You'd at some point try to use a language that let you use 'C' instead, probably.

@ZhongYu 2016-02-28 19:26:41

@HaakonLøtveit - can't you use the character directly, instead of the escape sequence, e.g. class Løtveit instead of class L\u00D8tveit

@Haakon Løtveit 2016-02-28 21:11:17

That would work great for me, but then you have to write "new Løe()" somewhere, and you'd probably get really tired of copypasting 'ø's real soon. Letting you sub \u00D8 those places would likely be easier on your sanity. (Or you'd just use the IBM international layout, but that's because it supports most western European characters. But then there's Pinyin etc.)

@ZhongYu 2016-02-29 00:32:17

@HaakonLøtveit -- I didn't have type or copy @HaakonLøtveit, the editor does it for me by auto completion. Same for Java. Even if I have to copy ø, it's probably easier than finding and typing its unicode.

@Haakon Løtveit 2016-02-29 09:02:10

Yes. Your editor today, in 2016 does that. But Java was released in 1995. Emacs didn't have semantic autocompletion back then, and was the most advanced thing that was available for Java. It didn't even have unicode support.

@Jonathan Gibbons 2015-06-09 18:45:36

This was an intentional design choice that goes all the way back to the original design of Java.

To those folks who ask "who wants Unicode escapes in comments?", I presume they are folks whose native language uses the Latin character set. In other words, it is inherent in the original design of Java that folks could use arbitrary Unicode characters wherever legal in a Java program, most typically in comments and strings.

It is arguably a shortcoming in programs (like IDEs) used to view the source text that such programs cannot interpret the Unicode escapes and display the corresponding glyph.

@Paŭlo Ebermann 2015-06-14 08:41:44

Nowadays we use UTF-8 for our source code, and can use the Unicode characters directly, no need for escapes.

@zwol 2015-06-09 15:16:40

The \u000d escape terminates a comment because \u escapes are uniformly converted to the corresponding Unicode characters before the program is tokenized. You could equally use \u0057\u0057 instead of // to begin a comment.

This is a bug in your IDE, which should syntax-highlight the line to make it clear that the \u000d ends the comment.

This is also a design error in the language. It can't be corrected now, because that would break programs that depend on it. \u escapes should either be converted to the corresponding Unicode character by the compiler only in contexts where that "makes sense" (string literals and identifiers, and probably nowhere else) or they should have been forbidden to generate characters in the U+0000–007F range, or both. Either of those semantics would have prevented the comment from being terminated by the \u000d escape, without interfering with the cases where \u escapes are useful—note that that includes use of \u escapes inside comments as a way to encode comments in a non-Latin script, because the text editor could take a broader view of where \u escapes are significant than the compiler does. (I am not aware of any editor or IDE that will display \u escapes as the corresponding characters in any context, though.)

There is a similar design error in the C family,1 where backslash-newline is processed before comment boundaries are determined, so e.g.

// this is a comment \
   this is still in the comment!

I bring this up to illustrate that it happens to be easy to make this particular design error, and not realize that it's an error until it is too late to correct it, if you are used to thinking about tokenization and parsing the way compiler programmers think about tokenization and parsing. Basically, if you have already defined your formal grammar and then someone comes up with a syntactic special case — trigraphs, backslash-newline, encoding arbitrary Unicode characters in source files limited to ASCII, whatever — that needs to be wedged in, it's easier to add a transformation pass before the tokenizer than it is to redefine the tokenizer to pay attention to where it makes sense to use that special case.

1 For pedants: I am aware that this aspect of C was 100% intentional, with the rationale — I am not making this up — that it would allow you to mechanically force-fit code with arbitrarily long lines onto punched cards. It was still an incorrect design decision.

@aioobe 2015-06-09 15:29:31

I wouldn't go as far as saying that it's a design error. I could agree with you that it was a poor design choice, or a choice with unfortunate consequences, but I still think that it works as the language designers intended: It enables you to use any unicode character anywhere in the file, while maintaining ASCII encoding of the file.

@supercat 2015-06-09 16:08:00

I would think that if the rationale was as stated, then backslash followed by some specific other character (e.g. !) should have indicated that the remainder of the physical line should be ignored, and the first character of the next line should be regarded as directly following the character before the backslash. That would allow \! to be punched in columns 71-72, leaving the eight columns available for sequence numbers. In some contexts the marker-stripe trick could lessen the need for machine-readable numbers, but I wouldn't think it would eliminate it.

@supercat 2015-06-09 16:09:56

That having been said, I think the choice of processing stage for \u was less absurd than the decision to follow C's lead in using leading zeroes for octal notation. While octal notation is sometimes useful, I've yet to hear anyone articulate an argument why a leading zero is a good way of indicating it.

@zwol 2015-06-09 18:33:01

@supercat The people who threw that feature into C89 were generalizing the behavior of the original K&R preprocessor rather than designing a feature from scratch. I doubt they were familiar with punched card best practices, and I also doubt that the feature has ever been used for its stated purpose, except maybe for one or two retrocomputing exercises.

@zwol 2015-06-09 18:34:32

@supercat I wouldn't have a problem with Java \u as pre-tokenization transformation if it were forbidden to produce characters in the U+0000..U+007F range. It's the combination of "this works everywhere" and "this aliases ASCII characters with syntactic significance" that demotes it from awkward to flat-out wrong.

@supercat 2015-06-09 18:42:04

@zwol: I could go along with that, though in general I'm not a big fan of how languages approach non-ASCII identifiers. Since Unicode includes a lot of homoglyphs, and languages that allow Unicode identifiers often impose minimal restrictions on their use, it's excessively difficult to produce a program listing which is human readable but semantically unambiguous.

@zwol 2015-06-09 19:17:58

@supercat Yeah, even Unicode's own recommendations for how to do identifiers in programming languages are too loosey-goosey for me to be comfortable with.

@supercat 2015-06-09 19:25:39

@zwol: Personally, I think programming languages should define tight and loose matching criteria, and require that identifiers must match tightly to be considered a match, but should shadow all identifiers that match loosely (such a rule should apply to upper/lower case in ASCII, but also in many Unicode scenarios). Thus, if Foo is defined in an outer context and foo is defined in an inner one, then within the inner context foo would refer to the latter identifier and Foo would be a syntax error. Applying such a rule to homoglyphs, but with a means to override it in special cases...

@supercat 2015-06-09 19:33:47

...(e.g. explicitly tell the compiler "I want identifiers foo and Foo, or Χ and X, to both be accessible here) would help guard against a lot of ambiguous situations.

@Holger 2015-06-09 19:44:53

@supercat: today, IDEs do that. The “loose matching criteria” often consists of a single letter, then the IDE fills in the remaining characters to make it an appropriate “tight matching criteria” and I don’t think that compilers should ever deal with the “loose matching criteria”. I.e, I don’t wont a compiler that happily resolves occurrence of i to I and when somebody compiles it on a Turkish locale, i is suddenly resolved to İ

@supercat 2015-06-09 19:52:55

@Holger: Under the rules I'd like to see, within a scope where Six was defined, identifiers six, SİX, Sıx, etc. would not be usable, even if they existed in outer scopes. Collisions may result in syntax errors that require an explicit "distinguish these identifiers" directive, but could not change the meaning of code that still compiled.

@Mark Hurd 2015-06-16 17:39:11

On your "for pedants": Of course at that time the // single-line comment didn't exist. And since C has a statement terminator that is not a new line, it would mostly be used for long strings, except that as far as I can determine "string literal concatenation" was there from K&R.

@Pepijn Schmitz 2015-06-10 17:37:17

I'm going to completely ineffectually add the point, just because I can't help myself and I haven't seen it made yet, that the question is invalid since it contains a hidden premise which is wrong, namely that the code is in a comment!

In Java source code \u000d is equivalent in every way to an ASCII CR character. It is a line ending, plain and simple, wherever it occurs. The formatting in the question is misleading, what that sequence of characters actually syntactically corresponds to is:

public static void main(String... args) {
   // The comment below is no typo. 
 System.out.println("Hello World!");

IMHO the most correct answer is therefore: the code executes because it isn't in a comment; it's on the next line. "Executing code in comments" is not allowed in Java, just like you would expect.

Much of the confusion stems from the fact that syntax highlighters and IDEs aren't sophisticated enough to take this situation into account. They either don't process the unicode escapes at all, or they do it after parsing the code instead of before, like javac does.

@bvdb 2017-06-22 12:59:41

I agree, this isn't a java "design error" , but it's an IDE bug.

@Phil 2018-06-15 05:37:34

The question is rather about why code that looks like a comment to someone not familiar with this particular aspect of the language and perhaps without reference to syntax highlighting, is in fact not a comment. Objecting on the basis of the premise of the question being invalid is disingenuous.

@jmoreno 2019-02-06 12:00:01

@Phil: it only looks like a comment when viewed with particular tools, others show it otherwise.

@Phil 2019-02-07 08:15:37

@jmoreno one should not have to have anything more than a text editor to read code. At the very least, it violates the principal of least surprise, namely that // style comments continue until the next \n character - not to any other sequence which is ultimately replaced by \n eventually. Comments are never expected to be anything other than stripped. Bad preprocessor.

Related Questions

Sponsored Content

13 Answered Questions

[SOLVED] Why does Java have transient fields?

  • 2009-05-26 12:11:36
  • Animesh
  • 644183 View
  • 1343 Score
  • 13 Answer
  • Tags:   java field transient

46 Answered Questions

[SOLVED] Does a finally block always get executed in Java?

30 Answered Questions

[SOLVED] How to avoid Java code in JSP files?

  • 2010-07-05 07:24:06
  • former
  • 268926 View
  • 1611 Score
  • 30 Answer
  • Tags:   java jsp scriptlet

6 Answered Questions

[SOLVED] Java - Method executed prior to Default Constructor

  • 2015-09-21 06:27:44
  • Rohit Nigam
  • 4746 View
  • 28 Score
  • 6 Answer
  • Tags:   java constructor

14 Answered Questions

[SOLVED] Why does this code using random strings print "hello world"?

  • 2013-03-03 04:38:06
  • 0x56794E
  • 190209 View
  • 1695 Score
  • 14 Answer
  • Tags:   java string random

518 Answered Questions

[SOLVED] What is the best comment in source code you have ever encountered?

  • 2008-10-08 20:08:07
  • Thomas Bratt
  • 2836365 View
  • 360 Score
  • 518 Answer
  • Tags:   comments

1 Answered Questions

[SOLVED] Is it possible to write a program in Java without main() using JDK 1.7 or higher?

  • 2014-05-19 17:41:18
  • user1852957
  • 2018 View
  • 3 Score
  • 1 Answer
  • Tags:   java jdk1.6 java-8

1 Answered Questions

[SOLVED] Unicode escaped comments in Python

Sponsored Content