I wanted to use a particular option -DentityExpansionLimit in java using a jdk and I was unsuccessful on an old version. I there anyway I can see which was the version this option was first implemented on? I was unable to find any answers and was hoping there is like a guide where an option was first implemented or even all the new features implemented for each version. Please let me know.
Seems like it was first introduced in Java 1.4.
Reference Links:
http://docs.oracle.com/javase/7/docs/technotes/guides/xml/jaxp/JAXP-Compatibility_160.html
http://www.oracle.com/technetwork/java/javase/relnotes-139182.html
As per the link:
New system property to limit entity expansion
The entityExpansionLimit system property lets existing applications constrain the total number of entity expansions without recompiling the code. The parser throws a fatal error once it has reached the entity expansion limit. (By default, the limit is set to 64000.)
To set the entity expansion limit using the system property, use an option like the following on the java command line: -DentityExpansionLimit=100000
I think your best option is to use google and check the release notes of each version.
Example: http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-429209.html
In your case, seems like your flag comes from JSDK v1.4.2
Related
In Java, I often see JAR files named with the version number of the software (jsoup-1.11.2.jar), while others are not (freemarker.jar).
Is this just a best practice/convention, or is there some functional reason for it?
Simple answer: no, this is purely a convention.
Obviously, tooling that checks versions can do that easily when version numbers are hard-coded like this. But there is no generic (like jvm based) tool relying on it.
And beyond that - sometimes this scheme is even counter productive. In our self grown build setup we have to always remember to update the build scripts after replacing JAR files - because a new version changes the file name (because version part of the file name).
Having the version in the name of the file allows you to quickly determine which of the n files you have is the latest. Also if you have no way of determining what the version is from within the program it can be helpful.
Eclipse Data Tools Platform has a “Driver Definitions” entry, where you can indicate the JDBC drivers you want to use. When adding one, the wizard asks you to select a “driver template” from a provided list. In my eclipse Neon Java EE version, the list contains, among others, [Name=Other Driver; System Vendor=Derby; System Version=10.2], and [Name=Other Driver; System Vendor=Derby; System Version=10.1]. I can’t see a difference between these two templates, except that they end up with different indicated System Version as a result of the wizard (expectedly). However, in both cases (selecting the 10.2 line or the 10.1 line), when the wizard asks for a jar containing the driver, I use a jar containing the 10.10 version, so this indicated System Version is incorrect in both cases.
My questions are: how does eclipse use these version numbers? If it does not use them, why does eclipse bother displaying a list with different entries for different versions? Can I get problems if the version of the driver I use does not match the indicated one? Should I somehow tell eclipse the right version I use?
The system version is the supported (minimum) version of the target database. The definition of a higher version can contain new features, keywords, data types etc of that database version. In other words: improved/closer support for the database version you are targeting.
For example on of the differences between the Derby 10.1 definition and Derby 10.2 definition is the default length reported for blobs:
In 10.1:
<predefinedDataTypeDefinitions xmi:id="BINARY_LARGE_OBJECT_1" lengthSupported="true"
defaultLength="1024" maximumLength="2147483647" primitiveType="BINARY_LARGE_OBJECT" jdbcEnumType="2004" javaClassName="java.sql.Blob">
In 10.2:
<predefinedDataTypeDefinitions xmi:id="BINARY_LARGE_OBJECT_1" lengthSupported="true"
defaultLength="2147483647" maximumLength="2147483647" primitiveType="BINARY_LARGE_OBJECT" jdbcEnumType="2004" javaClassName="java.sql.Blob">
Sometimes there might be no difference at all, but a separate (identical) definition might be provided just to avoid confusion for users to indicate that version is supported, and to make it easier to add corrections/improvements at a later time for that specific database version if necessary.
In short: use the version that is closest (but lower than or equal to) the version you are targetting; in this case: use the 10.2 definition.
I'm writing documentation for my java file. In that documentation, I want to add some html links at the end of each generated file. For that, what I have to use while writing java documentation?
If you are using Eclipse as IDE, you can use the plugin JAutodoc:
http://jautodoc.sourceforge.net/
To add a default text at the beggining of each text file.
According to the javadoc manual (can't find a newer version right now), you should use -footer when you generate your java API documentation from the CLI, for instance:
javadoc -footer "<b>Copyright 2015 Lakshmi Prasanna</b><br>" com.mypackage
Here's a similar example, but that uses -header instead.
Now, if you use a good IDE, at the very least it should allow you to type that somewhere in the project settings. Back in the day Eclipse wasn't very flexible, so I had to make an Ant script (yuck).
EDIT:
One limitation with this approach is that the CLI -options depend on the tool. This works with the standard javadoc command but might not work with another vendor's doclet. However I'm not sure there's a universal way to achieve what the OP asked.
Anyway, it seems to be: NOT -footer but -bottom.
JXLS 2 is not backward compatible with version 1. There are no upgrade instructions and while I can get things working with version two I'm having two issues.
Version 1 did not require use of comment tags, but now I cant get the output to generate without them.
Java code must specify which worksheet location to write the results, in version 1, output was written on top of the template which did not require duplication of template settings in Excel and Java code.
If I cannot find a workaround to these two issues, I'll have to go change every single template to use comments. But worse, I'll also have to make my java code aware of the template worksheet layout. I dont understand why this is the default behavior. Is there any way to get version 2 to behave more like version 1?
Version 1 did not require use of comment tags, but now I cant get the output to generate without them.
This is not completely true. You can choose not to use XlsCommentAreaBuilder. In this case you have 3 options
Use XmlAreaBuilder (probably not the way you want)
Use Java API to build the commands (probably not the way you want)
Create your own Jxls1TagCommandAreaBuilder which will build the commands from the Jxls-1 tag notation (and contribute it to back to jxls core)
The 3 option is probably the best because you will be able to use Jxls-1 templates with Jxls-2 without changes. Sure it is not trivial but should be possible.
Java code must specify which worksheet location to write the results, in version 1, output was written on top of the template which did not require duplication of template settings in Excel and Java code.
To get the Jxls-1 behaviour here you can just do something like this
for (Area xlsArea : xlsAreaList) {
xlsArea.applyAt(
new CellRef(xlsArea.getStartCellRef().getCellName()), context);
}
So you simply apply an area at its starting cell.
If you wish this to be a default behavior you can raise an improvement in jxls issue tracker
I'm using com.sun.net.httpserver.HttpServer in my project. However, it seems that the server leaks connections when it gets invalid data from the HTTP connection. The bug is this one:
http://bugs.sun.com/view_bug.do;jsessionid=dfe841c3152d878571573bafceb8?bug_id=6946825
Now, this is reported to be fixed in version "7(b94)" - however, we are still using Java 1.6 and it is unlikely that we would want switch Java versions at this point.
So, I am looking for ways to fix this situation. I don't have a lot of time, so I'd prefer quick solutions that work for now, over reimplementing a lot of things for later.
I have a few ideas on how to go about this:
Update to a more recent Java - this is something I don't want to do.
Find a jar which only contains a more recent version of com.sun.net.httpserver and make sure that jar loads before the system jars.
Find a drop-in replacement for com.sun.net.httpserver - I'm open to pointers here.
Modify code to work with another embedded HTTP server, hopefully one that isn't too different from the current one. I can rewrite the server setup code, somewhat, but most of the interfaces should stay the same.
Decompile the com.sun.net.httpserver.ServerImpl class, fix the offending places, and recompile that single class to a jar of it's own
But, I'm open to good suggestions!
Thank you in advance.
Fix is now implemented and works. I will paste here the relevant bits if anyone else needs these:
final Field httpserverimpl_server = Class.forName("sun.net.httpserver.HttpServerImpl").getDeclaredField("server");
final Field httpsserverimpl_server = Class.forName("sun.net.httpserver.HttpsServerImpl").getDeclaredField("server");
final Field serverimpl_allconnections = Class.forName("sun.net.httpserver.ServerImpl").getDeclaredField("allConnections");
final Field httpconnection_closed = Class.forName("sun.net.httpserver.HttpConnection").getDeclaredField("closed");
httpserverimpl_server.setAccessible(true);
httpsserverimpl_server.setAccessible(true);
serverimpl_allconnections.setAccessible(true);
httpconnection_closed.setAccessible(true);
Object serverimpl = httpserverimpl_server.get(server);
Set allconnections = (Set)serverimpl_allconnections.get(serverimpl);
LinkedList<Object> toRemove = new LinkedList<Object>();
for (Object conn : allconnections) {
if (httpconnection_closed.getBoolean(conn)) {
toRemove.add(conn);
}
}
for (Object conn : toRemove) {
allconnections.remove(conn);
}
Could you put a reverse proxy infront of the HTTP server, to make sure you only allow known good requests to come through? Varnish or Squid or Apache?
Or knock something up in Jetty so that it acts as a reverse proxy?
Another approach would be to grab the source code of the fixed version, rename the class and package so that it fits into your project, make the class public, and then use that implementation instead.
I can understand your reluctance to upgrade to a pre-release build of Java 7.
Here are my suggestions:
Get a Java support contract from Oracle and get them to provide you with a patch for Java 6 that fixes the bug.
Download the Java 6 sources for the release you are currently using, backport the bug fix from the Java 7 sources and build. Maybe you only need to do a build of certain JAR files.
Look at the code and see if you could develop a workaround. For example, you might be able to use reflection to dig out the "list of HttpConnection instances" that the bug report talks about, and periodically remove entries that look like they are dead. (I'd treat this as a last resort.)
(Updated: 2012-05-15)
And, now that Java 7 is well and truly released (we are now at 1.7u4):
upgrade to Java 7, and
get rid of the nasty reflective hacks that you used as a TEMPORARY workaround.
Do you have access to 7(b94)? Then you can compare the sources and see whether you can fix it by overriding or providing different accessors.