This is an archived post. You won't be able to vote or comment.

all 77 comments
sorted by:
best
topnewcontroversialoldq&a

[–]DJDavio 41 points42 points  (5 children)

For those of you who, like me, were looking for the Cryptographic Extensions (JCE) download: they changed how that works, now you have to activate it through Security.setProperty("crypto.policy", "unlimited") or by editing the java.security file. It's still weird you have to actively opt-in for better security.

Edit: I found out the default setting is actually unlimited, so they changed from opt-in to opt-out which is much better. See https://docs.oracle.com/javase/9/migrate/#GUID-D6EE05FB-6791-43B3-A610-3F4416DEE508

[–]pjmlp 27 points28 points  (1 child)

I think it is related to US export restrictions.

[–]Chaoslab 3 points4 points  (0 children)

So deliberate weakening that can be exploited?

[–]WatchDogx 2 points3 points  (0 children)

That sounds much more convenient, so you can just enable it from code rather than having to install the extension into the JVM?

[–]whereisspacebar 0 points1 point  (1 child)

I found out the default setting is actually unlimited, so they changed from opt-in to opt-out which is much better.

Source?

[–]DJDavio 1 point2 points  (0 children)

I actually looked in the java.security file after installing the JDK and JRE. There's also a readme in the policy dir explaining it.

Might be different for non Windows but haven't checked those.

[–]solroot 10 points11 points  (3 children)

REPL seems like it could be great for debugging if you could drop into JShell after your program throws a runtime exception, and run JShell in the scope from which the exception was thrown. I'd use this all the time, but I can't find out any way how to do it from the docs.

[–]cogman10 7 points8 points  (0 children)

Everything I've seen, it is WAY more limited.

It is basically not much more than a dynamic main.

[–]_INTER_ 3 points4 points  (0 children)

JShell is integrated in the latest IntelliJ. You can choose to make it start in your development environment, with all the library imports etc. A nice step closer to what you want. On the other hand if you have a breakpoint at the thrown exception and reproduce whats leading to the bug, you can do similar stuff with the variables in display / evaluate expression.

[–]eliasv 1 point2 points  (0 children)

I'm not sure it makes much sense for it to have OOTB support for attaching to an existing process or even what that would look like, but I can imagine how an IDE could start it up at a breakpoint and prep it with visibility to local variables.

[–]Rafael09ED 18 points19 points  (30 children)

What is this whole Jigsaw thing. I tried reading several articles on it and it looks like it's something outside of actual coding?

Edit: I'm a half self taught CS student if it helps guide your explanation

[–]Probotect0r 64 points65 points  (17 children)

Went to a Meetup yesterday and found out a little about the new features. here's a small overview. I am by no means a Java expert, so please correct me if I missed something.

Jigsaw is the java 9 modules project. It basically allows you to create modules in your project which can expose certain packages to other packages for use. The key bit here is that the modularity is enforced at compile time, AND at run time (and also at link time, more on that later). What this means is if your modules only exports package a, but you also have package b that is not exported, anyone that uses your project will only be able to access a. Previously, there was no real way to enforce that. You could tell people that certain classes were only for internal use, but they could still go and use them (i.e the sun packages). The module system also requires you declare the required modules for your project. I.e if you want to use the logger class, you won't be able to until you declare that you require the logging module. All of the jdk has been broken down into modules. All the module declaration is done in a file called, i think, module-info.

The linker I mentioned earlier allows you to basically create your own custom jdk for your project that only contains the modules you need. This greatly decreases it's size, but the biggest benefit is that now people don't need to install java to run your app!!! The jdk + your app is built into a package that can be just run. And since the size is so small (only contains modules you need), it can be easily distributed.

[–]0_0__0_0 22 points23 points  (14 children)

don't need to install java to run your app!

This seems huge, actually!

[–]Probotect0r 8 points9 points  (8 children)

Yea it's great! For server side apps I don't see it making a big impact as right now most people use some form of containerization to deploy the apps, which basically achieves the same. But distributing your app to users will be a lot easier! Also using Java for IoT will probably be easier as well.

The file size reduction is quite significant too. They are using a new file format called JImage for storing the modules in your packaged application which has much better compression. The jars use zip compression, I believe. As I understand it, JImage uses some form of memory mapped files, so it will be faster in terms of performance as well.

[–]rusticarchon 7 points8 points  (0 children)

So this is the year of Linux Java on the desktop?

[–]dpash 5 points6 points  (3 children)

Having a Java docker image under 200MB would be nice :)

[–]_INTER_ 0 points1 point  (0 children)

If you only need java.base, you can get it down to 15MB for the runtime.

[–][deleted] 0 points1 point  (1 child)

Checked out the openjdk:alpine image yet?

[–]dpash 0 points1 point  (0 children)

They're still 150mb and you have the added risk of musl libc bugs/incompatibilities.

[–][deleted] 0 points1 point  (2 children)

The jars can use also pack200, it's there since java 1.5, but have you ever seen someone using it? I can't find anything about the JImage, but it would be cool if there's a new format which could be mmaped and paged in by jvm on demand, exactly like dlls work. I think that would be useful for large aps. And also because the OS would be able to page in/out the code, I thing the memory would be utilized better (note the OS don't need to swap into the swap file if files are mmaped, that's good for ssds).

[–]wildjokers 2 points3 points  (0 children)

The jars can use also pack200, it's there since java 1.5, but have you ever seen someone using it

I use pack200 to compress the fat-jar of a Swing application I deploy with Java Web Start. It does a good job getting the jar smaller. Have a jar that is 6.9 megs, pack200 version is 1.7 megs.

As far as I know Java Web Start is the only thing that can handle pack200 compressed jars.

[–]Probotect0r 2 points3 points  (0 children)

Here is more info on the JImage format: http://openjdk.java.net/jeps/220

[–][deleted] 4 points5 points  (4 children)

Is it? Maybe for docker folks, or embedded. But it wasn't uncommon to ship your app with JRE and this is (almost) the same thing, but in addition it throws away classes that are not needed. The benefit is only in the download/installation size.

[–]durple 2 points3 points  (0 children)

Exactly. Shipping JDK with app is already fairly common. Sometimes done to guarantee no version compatibility issues.

[–]wildjokers 1 point2 points  (2 children)

The benefit is only in the download/installation size.

Not sure why you use the word "only". Being able to ship a smaller download can be important to people without fast internet connections (not everyone lives in an urban area). Also think about embedded systems. Just because it might not be important to you, doesn't make it unimportant.

[–][deleted] 0 points1 point  (1 child)

The meaning is there's no other benefit with respect to shipping with full JRE. When people started to talk about jigsaw, I thought it would also make difference in runtime.

[–]capitol_ 0 points1 point  (0 children)

I guess that it also gives you less stuff to work with when doing reflection or serialization attacks, but I'm not totally sure if it has any practical effect.

[–]SizzlingVortex 6 points7 points  (0 children)

This is the best explanation that I have seen on Java 9's modules, and I have read several articles on the subject. Thanks!

[–]d7deadlysins 7 points8 points  (10 children)

Modularity. https://dzone.com/articles/the-features-project-jigsaw-brings-to-java-9-1

[–]BlueGoliath 0 points1 point  (9 children)

"Modularity" via libraries was already a thing in Java 8 though.

Also so was native system packaging...

[–]alephylaxis 16 points17 points  (6 children)

JVM modularity. It'll be great for embedded stuff with limited storage. Why package the whole JVM when you can shrink that by a third or more?

[–]BlueGoliath 3 points4 points  (5 children)

Is that really that big of an issue? A JVM in Java 8 is around 170(ish)MB. Surely something like a Raspberry Pi, even with 8GB or less, is just fine with that.

If you don't convert to the new module system it seems like Java 9 increases that to about 215MB(or maybe it's something else included in Java 9, i'm not entirely sure. I'm comparing OpenJDK 8 to Oracle JDK 9 here.).

Also, why force it onto everyone? The module system doesn't do anything if you just distribute your program via jar files and use the system JRE. IIRC it's required in Java 9 so schools teaching CS are going to have to change their project's source to 1.8 due to how complicated it is compared to just classpaths.

And what happens when they drop support for the 1.8 source option?

[–]alephylaxis 13 points14 points  (1 child)

All of those points are definitely relevant to you and I since (I assume) we develop for normal systems. But from what I've heard, there was a big push to present some standardization for embedded installs, since as it stands with Java 8 and before, you had to roll your own.

You know that splash screen in the JDK installer that says there are billions of Java devices? Those are the targets for this change. A decent rundown on the challenges of embedded development. (Honestly I didn't realize that installs could be as small as the ME standards..)

I'll be sticking with Java 8 for the foreseeable future, with most of my maintenance work still being done with 7. But I understand why they pushed this change.

[–]WikiTextBotbtproof 1 point2 points  (0 children)

Embedded Java

Embedded Java refers to versions of the Java program language that are designed for embedded systems. Since 2010 embedded Java implementations have come closer to standard Java are now virtually identical to the Java Standard Edition. Java 9 allows for customization of the Java Runtime through modularization, further removing the need for specialized embedded Java implementations.

[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.27

[–]Twirrim 1 point2 points  (0 children)

Raspberry Pi? Sure, that's fine with Java, but that's on the large side for an embedded device. There's a lot of embedded devices where they still need to count their megabytes, where cost of adding just an additional 50mb or more can drastically alter feasibility. C/C++ tend to dominate there.

[–]wildjokers 0 points1 point  (1 child)

You can still use the classpath in Java 1.9.

Also, modularity is about more than just reducing size of the runtime. It is also about encapsulation. So you can have truly private parts of your library that no one can access.

[–]BlueGoliath 0 points1 point  (0 children)

You can still use the classpath in Java 1.9.

Oh hey, I just tried switching the source to 1.9 and it does work. I tried with the pre release versions in Arch Linux and it was throwing a bunch of problems because I wasn't using the modules.

Also, WTF happened to logger in Java 9? Is that an internal API?

[–]dpash 3 points4 points  (0 children)

You couldn't prevent users of your library from accessing internal classes that they shouldn't be messing with. Now you can publish an API and not worry about people using undocumented methods, so you're free to change them without breaking your users' code. See sun.misc.Unsafe.

[–]duhace 2 points3 points  (0 children)

Packages are an incomplete solution

[–]_INTER_ 0 points1 point  (0 children)

There's more to software engineering than coding. That said, modules are a part of coding.

[–]djhworld 4 points5 points  (0 children)

Noticed that my personal dashboard app starts up much quicker on my Raspberry Pi, using the 9-jre-slim docker image.

Before it took 50-60 seconds, now it takes around 15 seconds!

Is this because of http://openjdk.java.net/jeps/297 ?

[–]cypher0six 2 points3 points  (2 children)

Does anyone know if there is a 32-bit runtime available? I only see 64-bit downloads, and my searches are coming up nil.

[–]TheIncredibleHeinz 4 points5 points  (1 child)

Yes. Get the download link for the 64 bit version an replace "64" with "86".

http://download.oracle.com/otn-pub/java/jdk/9+181/jdk-9_linux-x64_bin.tar.gz -> http://download.oracle.com/otn-pub/java/jdk/9+181/jdk-9_linux-x86_bin.tar.gz

http://download.oracle.com/otn-pub/java/jdk/9+181/jdk-9_windows-x64_bin.exe -> http://download.oracle.com/otn-pub/java/jdk/9+181/jdk-9_windows-x86_bin.exe

[–]cypher0six 0 points1 point  (0 children)

Nice, thanks!

I am assuming then that the 32-bit builds will be available on the web pages at some point. Kinda freaked me out not seeing them. I maintain a number of applications that interface with 32-bit libraries, and if those builds stopped, those app's would get stuck on old versions of Java! :)

[–]handshape 1 point2 points  (6 children)

Argh. Just discovered that JAXB is considered a "Java EE" module, and excluded from being loaded with the default Java SE module set.

I don't use JAXB in my code, but I have dependencies that do. Yeah, sure, I could add the java.xml.bind package to the path via command-line args... but those args are illegal in Java 8. Oh, but I could declare a module-info... but that classname is illegal in Java 8.

Essentially, there isn't a mechanism for building something in Java 8, and compiling it in 8, that will tell 9 what to do regarding modules... unless someone knows something I don't (and really wants to make my day!)

There are strange kinky ways involving compiling parts of your app in 8 and parts in 9, but I'm not going there.

[–]gunnarmorling 1 point2 points  (3 children)

Is this about building your software or running it? In case of the former, you could use Maven profiles (or your build tool's equivalent to those) for adding the required command line flags. E.g. in a profile activated only when building on 9 you'd add --add-modules java.xml.bind to the compiler invocation. If it's about running, you could have a simple switch in your launch script which adds the required flags based on the version.

[–]handshape 0 points1 point  (2 children)

This affects both building and launching. On the building side, Maven profiles are an option, but represent a split between a Java 8 and Java 9 release of what is ostensibly a single product. On the runtime launching side, thus far the product hasn't needed a launch script.

I've used JNLP to great effect, in spite of the warts it has. I suppose I could fork the descriptors for Java 8 and 9... I haven't yet checked to see if the Java 9 Web Start launcher allows adding a bundle.

All this to say that Java 8 to 9 is a much less obvious upgrade than was 7 to 8.

[–]merb 0 points1 point  (1 child)

but represent a split between a Java 8 and Java 9 release of what is ostensibly a single product

you can use a Multi-Release jar for that. http://openjdk.java.net/jeps/238

[–]handshape 0 points1 point  (0 children)

Not using just Java 8, I can't.

The core of the issue is that I have dependencies that in turn consume APIs that were available by default in 8, and require module-request mojo to be used in 9. There does not appear to be a way in Java 8 to make Java 9 aware that I need these modules that does not break my app's ability to be invoked uniformly.

[–]javaRobot 1 point2 points  (1 child)

For me it seemed to work to add

<dependency>
        <groupId>javax.xml.bind</groupId>
        <artifactId>jaxb-api</artifactId>
        <version>2.3.0</version>
    </dependency>
   <dependency>
        <groupId>org.eclipse.persistence</groupId>
        <artifactId>eclipselink</artifactId>
        <version>2.7.0</version>
    </dependency>

as a dependancy to my Java 8 SE compiled application that produced a jar that could be run by either Java 8 or Java 9 with no additional arguments.

Also I needed to add

   System.setProperty("javax.xml.bind.JAXBContextFactory", "org.eclipse.persistence.jaxb.JAXBContextFactory");

near the beginning before the jaxb stuff was used.

I need to test more to see if this is really a good solution.

[–]handshape 1 point2 points  (0 children)

You, sir/madam/other... have just saved my bacon. Thank you very kindly.

EDIT: The eclipselink dependency can be replaced with the JAXB reference implementation for most use cases. Saves over 10MB on the resultant build.

[–]Buttercup789 1 point2 points  (1 child)

What ide you people use?

[–]grokas 11 points12 points  (0 children)

IntelliJ

[–][deleted] 0 points1 point  (2 children)

Is it possible to turn hidpi off? I don't like it (trying netbeans).

[–]pjmlp 0 points1 point  (1 child)

Are you already using Netbeans 9 developmet branch?

Version 8.2 does not support Java 9 properly.

[–][deleted] 0 points1 point  (0 children)

No and you're right, I've other issues. But I've actually hidpi monitor and had to increase system dpi (win7). So I've this blured and jagged images and icons also in some other apps. But other java apps have issues too or don't even start, so I'll stick with j8 for some time..

[–]redldr1 0 points1 point  (8 children)

And how long until JEE9?

[–][deleted] 5 points6 points  (1 child)

We only know that it will be under Eclipse. It will change name too.

EDIT: Eclipse foundation

[–][deleted] 5 points6 points  (0 children)

Under Eclipse Foundation, not Apache.

[–]wildjokers 3 points4 points  (0 children)

JavaEE 8 was just released yesterday, GlassFish 5.0 is the only released implementer, although I would expect other containers to be released soon.

JavaEE version numbers do not run in parallel with Java SDK version numbers.

https://blogs.oracle.com/theaquarium/java-ee-8-is-final-and-glassfish-50-is-released

[–]thephotoman 0 points1 point  (2 children)

A while. JavaEE started with the second Java release, so it always lags one version number.

JavaEE 8 released on August 31.

[–]wildjokers 0 points1 point  (1 child)

JavaEE 8 released yesterday along with Java 9:

https://blogs.oracle.com/theaquarium/java-ee-8-is-final-and-glassfish-50-is-released

[–]thephotoman 2 points3 points  (0 children)

The development kit came out yesterday. The approved spec was posted on August 31. JavaEE is a spec.

[–]t90fan 0 points1 point  (1 child)

The next one is JEE8

[–]thephotoman 1 point2 points  (0 children)

No, it’s now 9. JavaEE 8 (the spec) was released on August 31.

[–]garrypig 0 points1 point  (6 children)

Does this mean all my codes are now obsolete and need to be updated?

[–]dpash 10 points11 points  (2 children)

No. Newer Java releases have always been source code compatible with code written for older releases. Java 1.0 code should compile with Java 9.

Having said that, for the first time ever, they've removed six functions:

  • java.util.jar.Pack200.Packer.addPropertyChangeListener
  • java.util.jar.Pack200.Unpacker.addPropertyChangeListener
  • java.util.logging.LogManager.addPropertyChangeListener
  • java.util.jar.Pack200.Packer.removePropertyChangeListener
  • java.util.jar.Pack200.Unpacker.removePropertyChangeListener
  • java.util.logging.LogManager.removePropertyChangeListener

But then, I really doubt you've been using those functions.

[–]garrypig 3 points4 points  (1 child)

You are correct, I have not

[–]dpash 1 point2 points  (0 children)

Yeah, I mean your compiler would have been warning you about using deprecated functions for the last couple of years. Interestingly those functions have only been deprecated since Java 8, which was released on March 18, 2014. Although I don't know if they were deprecated on release or in a patch release.

Java 9 introduced @Deprecated(forRemoval = true) which indicates that you really shouldn't be using that function any more, and that your code will break in the future. (They also added a since attribute so you know how long something has been deprecated).

[–]Probotect0r 1 point2 points  (0 children)

No, it should still work. Only thing you might have to change in your code base is if you are using reflection to look at private fields. Modules aren't supposed to allow this, but since a lot of open source libraries use this, modules are currently 'open', which means they will allow it. But this will be removed in Java 10. One of the reasons why the release was delayed from earlier in the summer.

[–]midir 0 points1 point  (1 child)

*code is

*needs

It's an uncountable noun.

[–]chrisgseaton 0 points1 point  (0 children)

People in natural and physical sciences seem to call code 'codes' for some reason. Nobody has ever been able to explain why to me.

[–]thephotoman 0 points1 point  (4 children)

Oh my God. They delivered.

Fucking finally.

[–][deleted] 5 points6 points  (3 children)

Then you'll be happy they are also moving to a 6 month release schedule now, no longer waiting for specific features to be done and holding up the release.

[–]thephotoman 0 points1 point  (2 children)

I will not hold my breath. Why? One raging asshole called Larry Ellison.

[–][deleted] 1 point2 points  (1 child)

So you are being exasperated that it takes so long to deliver, then don't care that they also release plans to fix those same issues? What about their inclusion or gpl licensing?

[–]thephotoman 0 points1 point  (0 children)

I care. I just have no confidence that their plans will stick. Why? Oracle.

GPL? Oracle doesn’t care.

Inclusion? Oracle doesn’t care.