15 ms·
Java 9 features announced
- mmastrac 12y agoThe lack of an official JSON API has been a huge sore point for quite some time and has spawned dozens of libraries re-implementing the same thing over and over (GSON, Jackson, and even my own nanojson). I do hope that we avoid the DocumentBuilderFactory mistakes of XML and just end up with One True JSON implementation this time.
- jug6ernaut 12y agoIm not sure i would call having multiple options a huge sore point. Chances are many of these options would still exist even if there was an official API. FYI: Just looked at your nanojson, looks good. Might have to try it out, i like the fluent api for object creation.
- th3iedkid 12y ago>>Im not sure i would call having multiple options a huge sore point It becomes one when serializing and de-serializing across a distributed application like xerces class path issues in different jvm implementations.Not a common sore point though! >> Chances are many of these options would still exist even if there was an official API. True and agreed.
- carsongross 12y agoAre you sure that's true? As you say, look at the "standard" API for XML parsing: a complete disaster. Dates, similar. Logging was slightly less disastrous because they took so much from Log4j, but they still made it unwieldy enough that the log4j guys ended up writing an API on top of that which everyone uses. Now, props where props are due: Sun crushed the collections APIs compared to other languages at the time. And that more than makes up for everything else. But I see little evidence that standardizing JSON parsing will improve things.
- mmastrac 12y agoI'll counter that with saying that j.u.l is not actually that bad, IMO, although I might be the only one in the world that thinks that. I always just choose j.u.l in my projects because it works well-enough. I just shim anything with slf4j if it speaks log4j or commons-logging (shudder). Perhaps Sun should have just adopted slf4j and a simple console-logging stub, but I don't think j.u.l is really any worse than the alternatives -- only a different implementation. Now date APIs: those do suck, but I think the new Date JSR will finally get things to a place where we can use Java Dates rather than Joda.
- wlievens 12y agoXML parsers are so complicated because XML and the DOM are more complicated. A json parser can be simpler.
- sgarlatm 12y agoI really don't see any benefit of introducing a JSON API into the JDK. Jackson works great already. Are they really going to make something that much better?
- mdaniel 12y agoThere is an official JSON API: https://jcp.org/en/jsr/detail?id=353 https://jcp.org/en/jsr/detail?id=353 But it is unclear how many of the existing implementations conform to it, and it definitely doesn't work toward your misguided One True JSON Implementation goal.
- karianna 12y agoThat's a Java EE API. I've been working with the Java SE and Java EE folks to make sure that a new version of that will sit on top of the core JDK 9 one.
- mdaniel 12y agoHow did you arrive at the conclusion that a set of interfaces is a JavaEE API? Above and beyond the fact that in section 2.2 of the JSR it plainly states: "This JSR is targeted for Java SE 6 or higher and Java EE 7 or higher platforms."
- karianna 12y agoWe helped test out the RI and TCK - it was in the end up built for Java EE in mind (that's not to say someone couldn't provide a stripped down version that could work for SE - but I don't think anyone has or will).
- timmclean 12y agoGson worked perfectly for me a few years ago. Why did you end up implementing your own?
- jgalt212 12y agoAmen to that, brother. JSON is a huge pain point for Java. No wonder so many Java folks keep defending XML--at least it's malleable in their home language.
- dandrews 12y agoSourced here: http://www.infoq.com/news/2014/08/Java9-FirstFeatures http://www.infoq.com/news/2014/08/Java9-FirstFeatures
- haddr 12y agoI'm deeply missing hot swapping. I believed it could be included in java 9 but i think we have to wait...
- curiousCoffee 12y agoWhat is hot swapping?
- ZoFreX 12y agoReplacing code while it's running. Currently this is possible but quite limited in the official JDK, you can only replace the contents of method bodies. Edit: Demo of it in action here, notch is rapidly developing a game in Eclipse by changing the code while it's running: https://www.youtube.com/watch?v=rhN35bGvM8c https://www.youtube.com/watch?v=rhN35bGvM8c
- exabrial 12y agoThere's always JRebel!
- pjmlp 12y agoNot really. http://zeroturnaround.com/blog/goodbye-liverebel/ http://zeroturnaround.com/blog/goodbye-liverebel/
- curiousCoffee 12y agoOh, damn! I just started using jrebel.. (I know I asked what hotswapping was but I was curious if the OP meant hotswapping in the same way as jrebel or something else) edit: Wait, that is liverebel, not jrebel
- pjmlp 12y agoAh, sorry! I though liverebel was the new name.
- lafar6502 12y agoLooks like they're actually listening to developers
- miralabs 12y agoa new json api to be released 2016. Hopefully by that time json is still relevant. I know most likely it will but at the pace of change that tech has, im not betting. is there any contender to json at the moment?
- exelius 12y agoWe're talking Java here. Java is used by enterprises all over the world for mission-critical code. I have clients who are just now making the move to Java 7; so of course JSON will continue to be relevant for the next 10 years or more. It may fall out of favor among the Julia/Erlang/Scala crowd, but JSON is here to stay for enterprises. As far as contenders to JSON, I can't really think of any besides XML. The biggest benefit to JSON is its simplicity; which becomes a huge drawback in a strongly typed language like Java.
- tonyhb 12y agoI don't think we'll be looking at a contender to JSON for quite some time (at least, for frontend/web consumable APIs). Being able to use it in JS directly pretty much guarantees its stability. For other message protocols it's a different story. Each system has its own needs, so it's much harder to say.
- Someone1234 12y agoJSON likely will be around as it is extremely simple (technologically) and extremely light (in terms of network usage). In order for a JSON killer to appear it would inherently have to be superior to JSON, and it is very hard as for what JSON is used for it does very well indeed. JSON somewhat replaced XML, but that made sense since XML is more complex and a lot more expensive (both in terms of network AND processing). I can see people building more complex obstractions on top of JSON in the next for years (essentially re-building what XML was, but in JSON) however I cannot really see JSON being entirely dethroned for what it is good at.
- justwannareply 12y agoYAML (http://www.yaml.org http://www.yaml.org) comes to mind, though I think JSON is a much bigger improvement over XML than YAML is over JSON.
- rufugee 12y agoNothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
- evacchi 12y agoKotlin is pretty nice for that. Also, project lombok is nice for Java code generation. I wish it became more "standard"
- sgarlatm 12y ago+1 It is pretty astonishing they haven't done something about that. It doesn't seem like it should be a very hard language feature.
- exabrial 12y agoAmen. How about some language keywords like "readable" and "writeable"? public class Foo { public readable int canSeeeMeButCantChange; public writeable int cantReadMe; public int existingBehavior; } These are pretty simple changes to the compiler and verifier. You would make canSeeeMeButCantChange an invalid "left hand" variable in the compiler, and the verifier would have to check for any writes to the fields. cantReadMe would be an invalid right hand variable, and a similar check for the verifier. Any other public field behaves as normal.
- exabrial 12y agoThe other "Missing feature" is null safe ".". Other languages have it, but I don't know what the technical name is... basically: Integer val = some.other.chain.of.objects.value; In Java, this code has a huge potential for NullPointerExceptions. Instead a new operator (yes, I know) like: Integer val = some.?other.?chain.?of.?objects.?value; If any of the intermediate objects are null, the whole assignment becomes null. This could be done with a smarter compiler (easy way), or a new JVM bytecode (probably 'better' but not easy).
- necubi 12y ago
- stusmall 12y agoI had heard a rumor that there ware talks of user defined value types. Does anyone know if there is any hope for this?
- quotemstr 12y agoWhat JVM instructions would you use to implement user-defined value types?
- Padding 12y agoI'm not sure you'd need to introduce new instructions. "user-defined value types", i.e. structs, can already be done today by (ab)using the Flyweight pattern and storing data (possibly off-heap with RAII rather than GC semantics) in some byte[]. All a JDK-supplied implementation would really need to do is (1) automate/hide all the painful work necessary to set this up and (2) provide syntactic sugar in the form of operators that can directly manipulate members of these types (+fast implicitly inlined implementations of them, specialized on the member types).
- danieldk 12y agoIt seems that it is almost in prototyping stage, the usual suspects have already written a sketch of a future proposal: http://cr.openjdk.java.net/~jrose/values/values.html http://cr.openjdk.java.net/~jrose/values/values.html
- stusmall 12y agoAwesome! Thanks. I don't know much about the path from idea to standardized feature with the JVM. Is there hope for it in Java 9 or is this much farther out in the future? Probably first and more importantly, what is the chance for this even ever happening?
- hyperpape 12y ago"the path from idea to standardized feature" Guy Steele was asking for value types in 1998 (http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf)
- sgarlatm 12y agoThis is a huge let-down after Java 8, but I guess that was inevitable. Lambdas are a tough act to follow and are probably my favorite addition to the JDK ever.
- adamlett 12y agoStill no hash literal :-(
- exabrial 12y agoNot really a place for it in a strongly typed language like Java :/ I could maybe see language support for creating Maps or something, but in Java you're supposed to create your own Objects and let the compiler check your code for errors.
- pswenson 12y agoI assume you meant statically typed, rather than strongly typed. Swift has this: var airports: [String: String] = ["TYO": "Tokyo", "DUB": "Dublin"]
- exabrial 12y ago:D Thanks for the correction I like the swift example... Map<String, String> map = new HashMap<>(){"TYO": "Tokyo", "DUB": "Dublin"};
- dragonwriter 12y agoA hash literal syntax in a strong, statically typed language works just fine; conceptually, they aren't much different in that regard than array literals, which Java already has.
- pjmlp 12y agoThere is a JEP for alleviating the problem. http://openjdk.java.net/jeps/8048330 http://openjdk.java.net/jeps/8048330
- mhaymo 12y agoAnd that JEP basically already exists in Guava https://code.google.com/p/guava-libraries/wiki/ImmutableCollectionsExplained https://code.google.com/p/guava-libraries/wiki/ImmutableColl... `ImmutableList.of("a", "b", "c")` is not as concise as e.g. Python, but it's not bad.
- CodeMage 12y agoI see that their "Process API updates" still don't make it possible to get a NIO Pipe object for redirected stdin, stdout or stderr when ProcessBuilder.Redirect.PIPE is used. Maybe they'll fix that some day...
- guelo 12y agoNo language features?
- karianna 12y agoThere maybe some small ones, but the (and I think correct) decision was made to focus on the JVM for Java 9. Java 8 bought in enough language features to keep Joe/Jane Java developers happy (most bleeding edge folks moved to Scala or other languages).
- pswenson 12y agoyawn.. Maybe around 2020 we'll get some useful stuff like string interpolation, long strings, default param values, and multiple return values!
- kclay 12y agoIs it possible to have native JSON parsing with JNI bindings to make parsing faster, or will the overhead cancel out any boost in performance?
- lmm 12y agoI'd worry about correctness more than performance. With a parser that's often used on remote documents, you really don't want there to be security flaws.
- kasey_junk 12y agoWhy wouldn't you be able to write JSON parsing fast in Java natively? Even if you can't, it's precisely the kind of thing that would pay a large JNI penalty.
- azinman2 12y agoBoxing and unboxing characters is a big part of performance penalties, especially when dealing with Unicode.
- arielweisberg 12y agoStill no solution for the GC fragmentation and pauses? Arbitrarily large heaps and data structures? They are going to improve lock performance, but do nothing to help people avoid locking like lightweight threads. Not waking up a thread and not locking is faster... It's weird how so many software projects completely lose sight of the fundamentals. I know I am biased due to how I use Java. I care very little for syntax and syntactic sugar. Reading and typing speed is not a problem for me. Get stuff done on time is and working around these shortcomings eats up my time.
- TheSageMage 12y agoWhat particularly is your issue around GC fragmentation? I ask because I had issues previously, but it was "solved" by moving to the G1 GC, I didn't know if you have considered the same.
- arielweisberg 12y agoG1 still fragments and does long compacting stop the world GCs. G1 pause times are still too long. G1 still doesn't have enough throughput. It's bad enough that people who care aren't using G1 yet. They still use CMS and small heaps and are careful to prevent promotion and fragmentation. You basically end up benefiting from GC for short lived allocations, but pay dearly for using Java when managing state the collector can't handle. I have not closely reviewed this benchmark but this was one person's experience http://blog.mgm-tp.com/2013/12/benchmarking-g1-and-other-java-7-garbage-collectors/ http://blog.mgm-tp.com/2013/12/benchmarking-g1-and-other-jav...
- Xorlev 12y agoWe had to switch from CMS to G1 when moving to JDK8 for reasons yet unknown, other than CMS used considerably more than CPU it had in JDK7. Fortunately, it's not a service that can't tolerate 500ms pauses here and there.
- karianna 12y agoI'd be cautious of a 2013 report. G1 has had significant work put into it over the past year and is much improved in its latest incarnations. We've seen best results with Java 8u5+ (Disclaimer: I run a company that sells a GC analysis tool).
- jaybna 12y agoDid they mention if spyware will continue to be in the installer?
- dtech 12y agoI thought one of the things promised in Java 9 was to finally fix the primitive mess, including all of the boxing and pointer chasing. Yet I can't find that here. I also thought that type reification was being researched. Does anyone know if either of these is still a thing?
- pron 12y agoYes, they are both being worked on. They're just not sure they'll be ready in time for 9.
- karianna 12y agoThe project to watch here is project Valhalla - valhalla-dev AT openjdk DOT java DOT net. Indeed the full solution of value types will not land until Java 10, but Java 9 will hopefully contain the very useful Collection of primitives enhancement (you can currently only have Collections of Objects, primitives are auto boxed into their Object equivalents at much greater overhead).
- cowardlydragon 12y agoA lightweight JSON API? Hopefully they don't consider the XML jdk monstrosity lightweight. Java SDKs haven't produced superior technology to OSS libraries for a decade, so I expect Jackson to still be better. The http client was so basic in the JDK it has spawned TWO apache HttpClients projects. Jigsaw... fool me three times? Wasn't this supposed to be in JDK7?
- pjmlp 12y agoList of proposed JEPs so far. http://openjdk.java.net/jeps/8048330 http://openjdk.java.net/jeps/8048330
- fortuitous 12y agoAs a side note, I realized java 7's Objects class was copied from google's Objects library class, but with name changes. They could have copied the apache API, but nope. This is fine by itself, but these are the same jerkoffs claiming some sort of copyright over the java JDK API. Quite disgusting.
- suprgeek 12y agoFix the Modularity business properly! Please simplify and make a standard system that most people can get behind. While Jigsaw started out ambitiously, I attended some of the initial meetings and the scope was....awesome. Then it scaled back to a re-org of the rt.jar to make it easy to run on mobile devices (Ironically we are seeing the full circle - Java started out as a Set-top box language, then graduated to an enterprisey kitchen-sink and now wants to come back to a modular approach). Now they seem to want to do some half-baked OSGI compliant approach. Have they used OSGI on medium/larger projects? There is literally no amount of money you can pay me to tackle something that hairy and complex.
- xpto123 12y agoSo the whole JDK will be based on modules that might or not be included in potentially different profiles (for example a Java ME equivalent?), or has that been dropped ? I remember seeing something about that in a presentation a few years ago. I think it's a good decision from Oracle to not include much more (compared to Jigsaw) in Java 9, given the huge scope of the Jigsaw change, which might probably be the change with the largest internal code impact so far ever done in Java, or at least one of the largest (if the plan to refactor the JDK for modules goes further).
- grizzles 12y agoMy Wishlist: 1. Fix Daemonization! Publish an official blessed and supported way of daemonizing processes. Yeah sure, you can use Apache commons-daemon and others of it's ilk. And it will work. But it will feel hacked together (at least it does to me). 2. Fix Dependency hell! Publish a blessed / supported / standard of supporting / managing different classloaders. Java has this great mostly unused mechanism (classloaders) for managing dependency hell. It would be great to have platform (maybe even language) level support to make that easy to do and a standard way of building software.
- andor 12y agoFix Daemonization This is fixed by process supervision software such as systemd -- no need to implement it yourself. Just leave your application running in the foreground. http://0pointer.de/public/systemd-man/daemon.html http://0pointer.de/public/systemd-man/daemon.html
- cgh 12y agoFor 2, what's required is a module system. OSGi provides such a mechanism but it's not "official". Each OSGi bundle has its own classloader. Java 8 was supposed to provide modules but they were scrapped so in the meantime, OSGi is the only option.
- karianna 12y agoProject Jigsaw (modularising Java itself and introducing a module system) will be a serious attempt at solving a part of this problem but may not land in its entirety for Java 9 (modularising the source code landed today on trunk). OSGi claims to solve the application layer part, but many developers I speak to have mixed results, primarily due tooling support etc.
- derengel 12y agoDoes anyone know if project jigsaw will improve the startup time for JVM languages?
- stevebot 12y agoSooo this means it will be what 5 years if never before Android starts to adopt some of these new Java 9 features? Kitkat introduced some Java 7 features, but I don't think anything in 8 is near to making it in.
- sapiogram 12y ago> improved support for multi-gigabyte heaps I've heard this thrown around before, but what this actually mean? Is it just some optimizations to the garbage collector?
- pas 12y agoWork on G1 GC. Now it can deal better with humongous regions (can collect them in mixed cycles, not just at the end of a slow and expensive full marking cycle), had a lot of fine tuning work done, and all in all, it seems to me that Oracle allocated/allowed/encouraged JVM GC developers to participate on the hotspot mailing list. ( http://mail.openjdk.java.net/pipermail/hotspot-gc-use/ http://mail.openjdk.java.net/pipermail/hotspot-gc-use/ ) And see also: https://bugs.openjdk.java.net/issues/?jql=project%20in%20(JDK)%20AND%20component%20in%20(hotspot)%20AND%20Subcomponent%20in%20(gc) https://bugs.openjdk.java.net/issues/?jql=project%20in%20(JD...
- gamesbrainiac 12y agoThis looks more like a minor update, and not as radical as Java 8.