1

I want to experiment with changes to the java library in java.lang, and possibly eventually other packages. This means instead of using rt.jar, I want to be able to separate out at least java.lang and compile to them.

It is not possible to edit source code for classes in java.lang if using rt.jar because they are already found in rt.jar.

I found the repo in mercurial: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/share/classes/

but no instructions on how to build.

I just built jdk by installing a jdk9, then using mercurial:

hg clone http://hg.openjdk.java.net/jdk/jdk/

I can successfully build the java executable and all utilities, but rt.jar is not in this package.

Dov
  • 8,000
  • 8
  • 46
  • 75
  • What about http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/f940e7a48b72/README ? – user158037 Mar 05 '18 at 13:18
  • Interesting. That file suggests loading jdk6, which is locked. I'm trying to understand how to get support from Oracle for doing that. Do you think the README can possibly be correct on that? It's bizarre how obfuscated this is. "We need to connect your user account to a Support Identifier. Access and privileges are approved by an Administrator in your organization. You need to add at least one Support Identifier to proceed." – Dov Mar 05 '18 at 13:45
  • Any Java from Java 6 onwards should work. – Stephen C Mar 05 '18 at 14:11
  • You are apparently trying to download one of the versions of Java 6 that was released after the last public release. You need a support contract for that. You can get the last Java6 public release from the Archive area without a support contract. – Stephen C Mar 05 '18 at 14:16
  • *" I'm trying to understand how to get support from Oracle"* - If you want Java support, contact Oracle sales. :-) – Stephen C Mar 05 '18 at 14:18
  • The point is there should be a way to build without loading an obsolete jdk. I don't believe that is the correct way, though I have to admit that the README is at least current. I found the repo for the jdk and it's building using jdk9, but does not contain the source code for rt.jar. – Dov Mar 05 '18 at 14:32
  • @Stephen your comments are not to the point. I will try to edit the question in case it is unclear – Dov Mar 05 '18 at 14:41

1 Answers1

1

The reason that your Java 9 build is not producing an "rt.jar" file is that Java 9 doesn't have an "rt.jar" or "tools.jar" anymore. As JEP 220 states:

"The class and resource files previously stored in lib/rt.jar, lib/tools.jar, lib/dt.jar, and various other internal jar files will now be stored in a more efficient format in implementation-specific files in the lib directory. The format of these files will not be specified and is subject to change without notice."

So ... basically ... your build of Java 9 is working.

If you want to do experiments with modifying parts of the Java class library, I suggest the following possible approaches:

  • Use Java 8 ... which has an "rt.jar"
  • Make the changes in your Java 9 source tree and build in the normal way.
  • Figure out how to inject your changes by modifying the Java 9 build procedure.
  • Figure our how the "implementation-specific files" work and inject your changes using the tools that the build procedure uses.
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I didn't see the source at first, but it's there! An easier way to build the libraries would be nice, because I would live with slower code while developing. If I could extract java.lang and override that would be great. But it's amazing having full access to the code. Thank you! – Dov Mar 10 '18 at 12:29
  • By implementation-specific they mean they build .so and .dll now, precompiled code -- significantly faster than java, optimized and not JIT load time. I haven't done benchmarks, but it's not so much that the code runs faster, but it starts MUCH faster. No lag -- you remember the old joke? Knock knock. Who's there. [long pause] Java. – Dov Mar 10 '18 at 12:32
  • The Java build infrastructure is there to support the needs of the Java team and downstream people who build Java for other platforms. While it would be "nice" if they supported folks doing experimental things, that is not their remit. I note your comments about Java performance. – Stephen C Mar 10 '18 at 12:33