5 ms·

Java 9 and IntelliJ IDEA

65 points by shock 9y ago

stevehiehn 9y ago
I'm excited to try Java9. I have an app that holds alot of strings in memory. I'm curious/hoping the 'compact strings' feature makes a noticeable difference on memory usage.
- shock 9y ago
  If you have many strings that are the same you can use String interning[0] to reduce the memory usage. 0 - http://java-performance.info/string-intern-in-java-6-7-8/ http://java-performance.info/string-intern-in-java-6-7-8/
  - nalllar 9y ago
    You will probably see better performance if you write your own string deduplication. https://shipilev.net/jvm-anatomy-park/10-string-intern/ https://shipilev.net/jvm-anatomy-park/10-string-intern/ > In almost every project we were taking care of, removing String.intern() from the hotpaths, or optionally replacing it with a handrolled deduplicator, was the very profitable performance optimization. Do not use String.intern() without thinking very hard about it, okay?
  - stevehiehn 9y ago
    That's not going to help my current situation, but either way, thanks, that's really good to know.
  - hyperpape 9y ago
    They're really different issues. Deduplication reduces the memory consumption of duplicate strings. Compact strings reduce the memory consumption of ascii strings, regardless of whether they're unique or mostly duplicates. So depending on your situation, you could want either, both, or neither. There is some overlap, however. If you have a lot of ascii strings but also a high level of duplication, either approach will save some memory, but if deduplication by itself saves x bytes, and compact strings saves y, using both will save a lot less than x + y bytes. And, like the later poster says, don't use String.intern() for deduplication.
    - shock 9y ago
      > They're really different issues. They're different fixes for the same problem: high memory usage. Depending on the situation you can use one or both, as you say.
- zipperhead 9y ago
  Isn't this already in java 8? As of update 20 you can set -XX:+UseStringDeduplication if you are using the new -XX:+UseG1GC garbage collector.
jansan 9y ago
Oh how I miss those code inspections and refactorings available for Java. Unfortunately I am forced to used Javascript at the moment and this language just plain sucks compared to Java, although Webstorm is trying really hard to support me. I really hope something like Java, or even better Kotlin, will replace Javascript in future for programming browser applications.
- salimmadjd 9y ago
  Have you looked into Elm or other strongly typed/functional languages?
  - jansan 9y ago
    No, because I did not exprect my project to become as big as it is now. Also, I am using a lot of third party libraries, and I am not sure if they would work seamlessly with another language that compiles to Javascript.
- Aeolus98 9y ago
  Scala.js scratches that itch for me. I rarely write frontend code, but when I do the extra IDE support given to me by IDEA for Scala.js is pretty great. I'm a full time Scala dev though, so I'm totally biased
  - virtualwhys 9y ago
    It is kind of surreal to look at a source file and not immediately know if it's Scala or Scala.js (like, oh wait, this is the front end). Just finished porting a legacy 5K Coffeescript front end over to Scala.js. Having a typed front end with all the power of Scala completely transforms the browser development experience. Great stuff. Only major drawback is generated js binaries incur a 160KB "tax", primarily due to size of Scala collections. Though, FWIW, the front end weighs in at 232KB non-gzip'd, and was able to scrap jQuery + DataTables + Modal window and Validation plugin dependencies -- shaved off about 200KB compared to previous front end.
  - deleted 9y ago
bitL 9y ago
Seems like Java9 forces more and more useless boilerplate needed for Jigsaw. Not sure I would call it a progress.
- SanderMak 9y ago
  Not really: using modules is completely optional. Small applications likely won't benefit from the structure and guarantees modules offer. Large-scale applications, however, will certainly benefit from strong encapsulation and explicit dependencies all enforced from compile-time through run-time (and adding an optional linking step for modules with jlink). (full disclosure: I'm author of Java 9 Modularity, O'Reilly, see https://javamodularity.com https://javamodularity.com)
  - bitL 9y ago
    How does it relate to OSGi? Also, if just one library uses modules, does it force modularization of everything else or can these two coexist in a reliable fashion?
    - SanderMak 9y ago
      Great questions. - OSGi: offers run-time modularization (based on classloaders), with a more dynamic model (bundles can start/stop/load/unload). Often derided for its complexity, which Jigsaw has tried to reduce (in part by offering a less dynamic model) - Forced modularization: fortunately, Java 9 has many migration features to allow incremental modularization. Most notable are automatic modules, which allow you to treat non-modularized JARs as modules, and interoperation between automatic modules and the classpath Hope this helps.
jzymbaluk 9y ago
It's a small thing, but I think JShell might be the feature of Java 9 I'm looking forward to most. When I was developing Python, being able fire up a REPL to poke at your code while you're writing it is a nice quality of life feature.
- kuschku 9y ago
  IDEA has a shell when in debugging mode already. So I just start my debugger, set a breakpoint, and can then poke around in the code directly, and inspect the state.
  - nickspacek 9y ago
    Eclipse also had one (strangely called "Display"), though as with most things I found IntelliJ's a bit more user-friendly.
0x0 9y ago
I don't see a java9 sdk on http://java.sun.com http://java.sun.com, do I need to look elsewhere? Will the normal Oracle distribution be updated later?
- batbomb 9y ago
  later today probably
- satysin 9y ago
  It should be released around 12pm PST.
erokar 9y ago
I wonder how many will consider switching to Kotlin instead of upgrading to Java 9. Kotlin is really just what Java should/could have been. It wouldn't surprise me if Kotlin has mostly replaced Java in 10 years.
- shock 9y ago
  There's a good chance it will go the other way around: Java will get more and more features from Kotlin.
- solomatov 9y ago
  Java 9 isn't only a language but it is also runtime, which is used by many languages including Kotline, and Scala.
sabujp 9y ago
download still not available at http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html http://www.oracle.com/technetwork/java/javase/downloads/jdk9... ...although it does say scheduled for release on 9/21
- mrks_ 9y ago
  I hear it will be available noon pacific time.
  - sabujp 9y ago
    thanks to jshell, i can now practice streaming without looking like a fool

65 points by shock 9y ago

I'm excited to try Java9. I have an app that holds alot of strings in memory. I'm curious/hoping the 'compact strings' feature makes a noticeable difference on memory usage.

shock 9y ago
If you have many strings that are the same you can use String interning[0] to reduce the memory usage. 0 - http://java-performance.info/string-intern-in-java-6-7-8/ http://java-performance.info/string-intern-in-java-6-7-8/
- nalllar 9y ago
  You will probably see better performance if you write your own string deduplication. https://shipilev.net/jvm-anatomy-park/10-string-intern/ https://shipilev.net/jvm-anatomy-park/10-string-intern/ > In almost every project we were taking care of, removing String.intern() from the hotpaths, or optionally replacing it with a handrolled deduplicator, was the very profitable performance optimization. Do not use String.intern() without thinking very hard about it, okay?
- stevehiehn 9y ago
  That's not going to help my current situation, but either way, thanks, that's really good to know.
- hyperpape 9y ago
  They're really different issues. Deduplication reduces the memory consumption of duplicate strings. Compact strings reduce the memory consumption of ascii strings, regardless of whether they're unique or mostly duplicates. So depending on your situation, you could want either, both, or neither. There is some overlap, however. If you have a lot of ascii strings but also a high level of duplication, either approach will save some memory, but if deduplication by itself saves x bytes, and compact strings saves y, using both will save a lot less than x + y bytes. And, like the later poster says, don't use String.intern() for deduplication.
  - shock 9y ago
    > They're really different issues. They're different fixes for the same problem: high memory usage. Depending on the situation you can use one or both, as you say.
zipperhead 9y ago
Isn't this already in java 8? As of update 20 you can set -XX:+UseStringDeduplication if you are using the new -XX:+UseG1GC garbage collector.

jansan 9y ago

Oh how I miss those code inspections and refactorings available for Java. Unfortunately I am forced to used Javascript at the moment and this language just plain sucks compared to Java, although Webstorm is trying really hard to support me. I really hope something like Java, or even better Kotlin, will replace Javascript in future for programming browser applications.

salimmadjd 9y ago
Have you looked into Elm or other strongly typed/functional languages?
- jansan 9y ago
  No, because I did not exprect my project to become as big as it is now. Also, I am using a lot of third party libraries, and I am not sure if they would work seamlessly with another language that compiles to Javascript.
Aeolus98 9y ago
Scala.js scratches that itch for me. I rarely write frontend code, but when I do the extra IDE support given to me by IDEA for Scala.js is pretty great. I'm a full time Scala dev though, so I'm totally biased
- virtualwhys 9y ago
  It is kind of surreal to look at a source file and not immediately know if it's Scala or Scala.js (like, oh wait, this is the front end). Just finished porting a legacy 5K Coffeescript front end over to Scala.js. Having a typed front end with all the power of Scala completely transforms the browser development experience. Great stuff. Only major drawback is generated js binaries incur a 160KB "tax", primarily due to size of Scala collections. Though, FWIW, the front end weighs in at 232KB non-gzip'd, and was able to scrap jQuery + DataTables + Modal window and Validation plugin dependencies -- shaved off about 200KB compared to previous front end.
- deleted 9y ago

bitL 9y ago

Seems like Java9 forces more and more useless boilerplate needed for Jigsaw. Not sure I would call it a progress.

SanderMak 9y ago
Not really: using modules is completely optional. Small applications likely won't benefit from the structure and guarantees modules offer. Large-scale applications, however, will certainly benefit from strong encapsulation and explicit dependencies all enforced from compile-time through run-time (and adding an optional linking step for modules with jlink). (full disclosure: I'm author of Java 9 Modularity, O'Reilly, see https://javamodularity.com https://javamodularity.com)
- bitL 9y ago
  How does it relate to OSGi? Also, if just one library uses modules, does it force modularization of everything else or can these two coexist in a reliable fashion?
  - SanderMak 9y ago
    Great questions. - OSGi: offers run-time modularization (based on classloaders), with a more dynamic model (bundles can start/stop/load/unload). Often derided for its complexity, which Jigsaw has tried to reduce (in part by offering a less dynamic model) - Forced modularization: fortunately, Java 9 has many migration features to allow incremental modularization. Most notable are automatic modules, which allow you to treat non-modularized JARs as modules, and interoperation between automatic modules and the classpath Hope this helps.

jzymbaluk 9y ago

It's a small thing, but I think JShell might be the feature of Java 9 I'm looking forward to most. When I was developing Python, being able fire up a REPL to poke at your code while you're writing it is a nice quality of life feature.

kuschku 9y ago
IDEA has a shell when in debugging mode already. So I just start my debugger, set a breakpoint, and can then poke around in the code directly, and inspect the state.
- nickspacek 9y ago
  Eclipse also had one (strangely called "Display"), though as with most things I found IntelliJ's a bit more user-friendly.

0x0 9y ago

I don't see a java9 sdk on http://java.sun.com http://java.sun.com, do I need to look elsewhere? Will the normal Oracle distribution be updated later?

batbomb 9y ago
later today probably
satysin 9y ago
It should be released around 12pm PST.

erokar 9y ago

I wonder how many will consider switching to Kotlin instead of upgrading to Java 9. Kotlin is really just what Java should/could have been. It wouldn't surprise me if Kotlin has mostly replaced Java in 10 years.

shock 9y ago
There's a good chance it will go the other way around: Java will get more and more features from Kotlin.
solomatov 9y ago
Java 9 isn't only a language but it is also runtime, which is used by many languages including Kotline, and Scala.

sabujp 9y ago

download still not available at http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html http://www.oracle.com/technetwork/java/javase/downloads/jdk9... ...although it does say scheduled for release on 9/21

mrks_ 9y ago
I hear it will be available noon pacific time.
- sabujp 9y ago
  thanks to jshell, i can now practice streaming without looking like a fool