I want to rebuild JDK1.6 after some changes in currency.java in the java.util package. so how can I do it? is there any compiler or builder to make a custom version of JDK?
I try $ javac src/java/util/currency.java but it did not work.
You should not build the whole JDK. Only thing you need is compile your class, put it into a .jar and place it in endorsed folder of a JRE.
I found these build instructions for OpenJDK 6 in the source code repository:
OpenJDK 6 Build README
UPDATE - revisiting this after a couple of years, I came across the following useful blog entry that has links to "Build README" files for a number of Java versions:
https://blogs.oracle.com/kto/entry/jdk_build_readme_collection
Lets hope it stays there, and stays current!
But yea ... if you have just changed one class, then the "endorsed directory" approach is a better idea; see #kan's answer.
Finally, it is generally a bad idea / undesirable to modify the standard class libraries to make your application work:
Your code is immediately non-portable. It will only work on your private flavor of Java.
Each time you upgrade your Java version you have to resync the sources and rebuild. (The "endorsed" approach is simpler, but you still have work to do on each Java update.)
There might be legal issues with redistribution of your modified Java. Talk to an IP lawyer ...
Related
In the coming version of Apache Netbeans, there's a new feature that looks impressive but I don't understand what it's all about.
https://github.com/apache/incubator-netbeans/pull/918
What is an expanded JDK? How can it be useful?
Expanded must be a synonym for exploded. This is hinted by the fact that this pull request is about using freshly compiled JDKs.
So, what is an exploded JDK then? This is explained at https://github.com/openjdk/jdk/blob/master/doc/building.md#running-make:
[An exploded JDK] is a minimal (or roughly minimal) set of compiled
output needed for a developer to
actually execute the newly built JDK. The idea is that in an
incremental development fashion, when doing a normal make, you should
only spend time recompiling what's changed (making it purely
incremental) and only do the work that's needed to actually run and
test your code.
The easy guess is that the terms expanded and exploded are used because, in this case, the modules are still available as a raw set of folders and class files instead of neatly compressed unique files. This last stage of neat packaging is a waste of time when you continually modify the JDK itself. So, it's skipped over while testing the JDK.
I wonder if anyone is using codenameone with lombok in Eclipse. I've googled, but all I could find is an old question of mine.
A tiny success
I've tried it, took a demo project, modified nothing and opened it in my Eclipse configured for Lombok. When compiling, I got the same stacktrace as here. I've added
/usr/lib/jvm/java-8-oracle/lib/tools.jar
to the path under Preferences -> Installed JREs -> Edit -> JRE system libraries (which may be a pure non-sense) and it didn't help.
Then I've replaced compiler="modern" by compiler="extJavac" in build.xml and it compiles. I can even use Lombok annotations and they compile and work in the simulator.
The problem
I'm afraid, this was the simple part. I guess, for submitting, I need to replace the source code by the output of delombok. I've tried to submit it as is and nothing happened (no error, no response).
Has anyone done it already?
Any tips?
You shouldn't change the classpath but if the bytecode has access to the properties then it should "just work". If you look at the build.xml file you will notice that it has targets for every one of the supported platforms and before the target occurs you will see a compilation target that packages the JAR that's sent to the servers.
Steve wrote a post about porting other languages to Codename One. This is simple by comparison.
It actually works! All I had to do was to
add the path to lombok.jar to the Java Build Path1
in the javac call of the jar task
replace compiler="modern" by compiler="extJavac"
add the path to lombok.jar to the classpath
1 This is not recommended as the dependency is unavailable on the build server, but that's exactly right. Lombok is a compile-time only dependency and the build seems to be based on the dist.jar, where Lombok has already done its job.
One year later: There was a problem with my old setup, so I installed everything anew and it seems to work. Just note that there are three javac tasks in the build.xml.
I attached the src.zip that came with my JDK, but it seems to be missing a few files.
It's as if I don't have any of the sun.*; packages. I would understand if they maybe got changed out for java.awt.AppContext, but that doesn't exit.
I found AppContext in Container.java (been looking at how Oracle does things), but it shows me bytecode instead of actual code.
Where could I get these files? I looked around on google and found nothing /:
Another thing, when I manually import sun.awt, my IDE shows me that the package exists, but no files in it. Maybe I need to upgrade my JDK? (version 7u45, not too bad)
EDIT on December 30, 2014: Still looking for an answer, now using JDK 8u25
Often time the jar files that are eventually distributed out do not contain the source code of the library but only the built .class files, either aiming to reduce jar size or protect their source code. You may have to refer other resources in order to view the source code. I find www.codatlas.com to be a pretty good place to view some java open source projects. You can find the source code of java.awt.AppContext. It has a pretty IDE-like interface so you should be able to figure out how to use.
These types can be found via the OpenJDK's jdk GitHub Repository.
Here's the implementation for sun.awt.AppContext, which can be found under src > java.desktop > share > classes > sun > awt
I was just curious to know this, when i give mvn install without doing 'clean', maven compiles only the modified java files. How does maven identify a java file is modified or not? I believe it is not using the last modified property of the file.
Reason for my belief: I had a module, after merging a change from svn, i gave mvn install and it didn't compile the modified file and when i looked at the change i saw that 'long' were modified to 'Long' in getters and setters.
So i just want to know how maven identifies if a java file has changed or not?
(P.S I'm using Apache Maven 3.0.3, if that matters)
I believe the Maven compiler plugin uses last modified dates on the source and class files to determine whether recompilation is necessary.
The compiler website is rather short on information, but the compiler:compile goal page has information on the following attribute, which finely tunes the staleness calculations: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#staleMillis. That's about the only official statement regarding staleness.
Without knowing much about maven, I can tell you that generally speaking, "make"-like tools use the "last changed" timestamp, which would explain the issue you had with svn ( see Wikipedia on Subversion's weaknesses.
Robert Scholte's comment at https://issues.apache.org/jira/browse/MCOMPILER-205 explains the process. It depends on the "useIncrementalCompilation" option of the "maven-compiler-plugin" (and on the version of it btw, I've only managed to have "useIncrementalCompilation" work with 3.1, not 3.0):
I see there's some confusion, so something needs to be changed, maybe
improving documentation is good enough. Looking at the code, you'll
see that non-incremental will only look at changed sourcefiles.
Incremental will also verifies if dependencies have changed and if
files have been added or removed. If it has changed, it'll remove the
complete classes-directory. The reason is that the default java
compiler is quite fast, likely much faster than analyzing per file
what to do with it. IIUC the eclipse compiler is a real incremental
compiler, so we could decide that based that based on the used
compiler not to drop the classes directory.
On MacOS (at least on SnowLeopard), the java command unconditionally adds an extra jar to the classpath:
/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/.compatibility/14compatibility.jar.
This jar contains a version of Apache Xerces+Xalan, unrenamed. This can cause chaotic results for applications that are trying explicitly to use some other versions of these libraries, particularly in webapps in servlet containers.
I tried to avoid this by using OpenJDK from MacPorts, but the MacPorts build failed for it.
Has anyone worked out some other recipe, other than the obvious violence of deleting that JAR file? It's recommended on one blog, but I fear that some Apple component or another will fail without it.
I haven't had any problems after renaming 14compatibility.jar. Perhaps you could try doing that. If anything breaks horribly, you could move it back in its original place.
I believe the ultimate trump card here is -Xbootclasspath/p:foo.jar . This lets you prepend a .jar to the bootstrap classloader. This should make it take precedence over anything I can imagine. For example you can replace java.lang.String this way.