21–30 of 60 posts
If that’s right, it’s exactly how the new release cadence is supposed to work—there’s no longer such a hard decision between delaying the release, leaving a feature to languish for several years, or releasing a feature without time to validate it.
Java Unicode escapes are kind of a mess, and the raw string literals proposal only makes it worse. Unicode escapes are processed in Java not just inside string literals, but everywhere in the source code. So, for example, the following program prints "Hello, world!" even though that line of code seems to be commented (\u000a is new line, so it ends the comment): public class Test { public static void main(String[] ar…
But those in C++ are deprecated, yay!
Java Unicode escapes are kind of a mess, and the raw string literals proposal only makes it worse. Unicode escapes are processed in Java not just inside string literals, but everywhere in the source code. So, for example, the following program prints "Hello, world!" even though that line of code seems to be commented (\u000a is new line, so it ends the comment): public class Test { public static void main(String[] ar…
What is the reason for Unicode escapes? It is something legacy from when Unicode was not universally accepted in all systems? Do other programming languages have this?
https://en.wikipedia.org/wiki/Digraphs_and_trigraphs
For example C has escape sequences for characters as basic as # and [.
Adding new syntax to Java is tricky (unless certain other JVM languages starting with C ;) but I was really disappointed in the string proposal. At the very least, have a default, optional string substitution feature. It ain't that hard and it's something users of raw strings will NEED anyways. What good is it to have snippets of raw strings that then need to be parsed again and split and re-glued again? JavaScript b…
Are you referring to Clojure or Ceylon? Or both, or neither?
Earlier quoted context omitted.
I don't think I've ever wanted SQL embedded in my Java source over loading it as a resource. Loading it as a resource allows me to edit the SQL in a sql-aware text editor.
IntelliJ is aware of SQL in text strings, and even validates it against the database schema. I like my SQL right next to the code that sets parameters, processes results, etc - mismatches are apparent (and also validated by IntelliJ).
Can someone explain to me why java has never considered as "import com.package.foo.bar as bar" feature? I really think fully qualified names can be disgusting when you have two classes of the same name.
- import com.package.foo.Bar -> use Bar.methodOfBar() in code
- import static com.package.foo.Bar -> use methodOfBar() in code
What does "import com.package.foo.bar as bar" add? Other than some kind of aliasing, as in you import Bar, but alias it as Baz, so then you use Baz.methodOfBar() ..?
Can someone explain to me why java has never considered as "import com.package.foo.bar as bar" feature? I really think fully qualified names can be disgusting when you have two classes of the same name.
Can someone explain to me why java has never considered as "import com.package.foo.bar as bar" feature? I really think fully qualified names can be disgusting when you have two classes of the same name.
What do you mean? You can do both: - import com.package.foo.Bar -> use Bar.methodOfBar() in code - import static com.package.foo.Bar -> use methodOfBar() in code What does "import com.package.foo.bar as bar" add? Other than some kind of aliasing, as in you import Bar, but alias it as Baz, so then you use Baz.methodOfBar() ..?
import java.util as jvutil;
import com.betterlist as better;
class Example {
jvutil.List list = new better.List();
}