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.
Related
The new version of Jython 2.7.0 standalone weighs in at 36155 KB; the previous released version 2.5.3 is 14005 KB.
Is there any way to safely remove functionality from the .jar file, if certain Python packages are not needed? I want to use the updated Jython release but the file size is an issue now, much more so than 2.5.3.
From the Jython developer mailing list:
Yes, sorry about that. We are focused on correctness first, then we
will go and trim down in subsequent 2.7.x releases, where x > 0. A
huge chunk of that additional bloat is supporting unicodedata and the
corresponding ICU4J jar we now use.
It should be a straightforward matter of programming to remove this
ICU4J dependency. Possibly this and other optimizations, especially
startup time, would be suitable for a Google Summer of Code student,
given that we are planning to participate this summer.
the reason it is bigger is that in the new version the compiled class files are included in the Lib folder.
see http://bugs.jython.org/issue1403 for a discussion
In the last entry there is a post where the speedup is measured with all class files removed from the Lib and included. So I conclude that it should be possible to remove the class files from the jar and zip it up again for a smaller package.
I'm looking at an application and it has the following statements
executeProcess("java.exe -cp { 500-characters worth of stuff } someProg");
This is done several times through the program, since this application launches other programs to perform certain tasks. The previous developers decided to just copy and paste again and again as long as it works.
The problems I have with this are
it's redundant. That classpath is copied a dozen times. I can refactor it and move it to a single location, so that's easy to deal with for now and makes life easier for the next guy that might have to maintain this thing.
everytime a program adds a new dependency, I need to update the class path. All of our libraries are stored in a single folder (with subfolders for different libraries), so I can't just use wildcards because they do not check recursively: -cp "path/to/lib/*
Currently I'm the only one maintaining our entire tool set, so if I add a library, I know what to do to make it work, but in general this seems like bad practice.
What are some ways to make these process calls easier to manage?
You can add it as an environment variable and then refer to that, if
that is feasible.
As you already suggested, you can refactor it to a
single location.
I have had good experience with using ant and maven-ant-tasks for launching java applications without managing the classpath manually. Of course, in order to do that you would have to use maven for build/dependency management or at least install your jars to a local nexus instance.
The end user needs to checkout a maven project that declares a list of top level runtime dependencies (transitive dependencies will be resolved automatically, for libraries that are maven projects) that also contains some ant scripts with targets that execute the application.
You will have to figure out how the java application will know the actual location of the ant scripts (an env variable maybe?), but it's an extremely superior solution to manual jar and classpath management.
This might look like a gargantuan task - and it kind of is - but the benefits of transparent jar version and classpath management are so huge, that I cannot even dare to remember how we did it in my current company before setting up the infrastructure for this.
Also, note that apart from installing ant (with maven-ant-tasks) and maven (with nexus configured) everything else you need to launch is on the SCM.
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.
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 ...
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.