I’ve recently been doing some work with code that is still running in a Java5 environment, to make matters worse, no new libraries can be added to the application. With these restrictions, I’ve had to resort to using only functions available in the standard installed JVM. The code relies on HTTP Basic authentication, and thus needs to use Base64 encoding.
The following classes were to be used…
Unfortunately, Eclipse did not like this and gave an error…
Access restriction: The type BASE64Decoder is not accessible due to restriction on required library C:\jdk1.5.0_22\jre\lib\rt.jar
Thankfully, this class (while not recommended, is in every build of the JVM that I have seen), you can tell Eclipse to only ‘Warning’ on it’s usage…
Window -> Preferences -> Java -> Compiler -> Error/Warnings.
Select Deprecated and Restricted API. Change it to warning.
Change Forbidden and Discouraged Reference and change it to Warning, or as needed.
BTW, I would normally rely on the
commons-codec.jar for this functionality, and use
org.apache.commons.codec.binary.Base64 for this purpose.
I’ve been a huge fan of the ‘
final‘ modifier in Java for function arguments and variables. While there’s some debate on their usefulness for performance, they definitely add in readability and understanding of code as developers are instantly notified by modern IDE’s and when they try to reassign such values as the compiler will indicate the error.
NOTE: Use of final for classes or functions often contradicts the paradigm of Object Oriented programming as you’ll be restricted from extending or overriding those items!
Categories: Work argument, code, compiler, final, ide, j2ee, java, keyword, modifier, performance, value, variable
I’ve often found that most JSP developers are uncertain as to why their HTML output contains a lot of extra blank-lines, tabs and carriage returns. White space included in the template text of JSP pages is preserved by default. This can have undesirable effects. For example, a carriage return added after a taglib directive would be added to the response output as an extra line. This cruft is known as WhiteSpace, and it is responsible for a lot of wasted bandwidth and many spacing issues in HTML designs.
- Developers that only use WYSIWYG editors are never even aware of the extra spacing within JSP source code.
- Developers that work in source code often want to format the markup to allow for better visualization and readability of the source code.
- Most IDE’s do not show the developers the special characters within the editor environment, external text editors such as NotePad++ and TextPad can be configured to show them.
Here’s a few suggested approaches on removing these, first development items:
- Remove comments:
- Remove any (and all) JSP style comments
<%-- comment --%> as each line in them will result in a carriage return being sent to the browser.
- While you are at it, remove HTML comments
<!-- comment --> as they often expose potential attack vectors for individuals trying to hack your website.
- Combine your JSP directives,
<%@page %> or
<jsp:directive.page /> into a single entry.
- Open and close all tags on a single line when possible.
Compiler options are possible for some platforms:
- The page directive on each JSP can contain the argument to tell the compiler to trim the space in individual JSP’s:
<jsp:directive.page language="java" pageEncoding="utf-8" trimDirectiveWhitespaces="true" />
- For Tomcat (and others?) web.xml can be edited to contain the following in the
- For Tomcat (and others?) web.xml can be edited to contain the following for the
- The deployment descriptor can also be used to do so by adding a
trim-directive-whitespaces element to a
jsp-property-group element in the deployment descriptor and set it to
- Some IDE’s expose the attribute, NetBeans 5.5 uses the following:
- Open the deployment descriptor file in the editor.
- Click the Pages button at the top of the editor.
- Select a JSP property group.
- Select the Trim Directive Whitespaces checkbox.
- Save the deployment descriptor.
- Custom tag authors can eliminate white space from the output generated by a tag file by setting the
trimDirectiveWhiteSpace attribute of the tag directive to
JSP Version Matrix for common servers:
|Apache Tomcat 7.0.x
|Apache Tomcat 6.0.x
|Apache Tomcat 5.5.x
|Apache Tomcat 4.1.x
|Apache Tomcat 3.3.x
|IBM WebSphere Application Server 7.x
|IBM WebSphere Application Server 6.x
|IBM WebSphere Application Server 5.x
Categories: Uncategorized bandwidth, compiler, deployment, descriptor, directive, jsp, network, performance, tags, trim, whitespace
I had an adventure tracking this one down lately, it seems that if your IDE saves files as UTF-8, the java compiler can’t always resolve the files.
Here’s the errors from the console output:
[ERROR] BUILD FAILURE
[INFO] Compilation failure
C:\Sandbox\Jars\example.jar\src\main\java\com\giantgeek\Example.java:[1,0] ‘class’ or ‘interface’ expected
C:\Sandbox\Jars\example.jar\src\main\java\com\giantgeek\Example.java:[1,1] illegal character: \187
C:\Sandbox\Jars\example.jar\src\main\java\com\giantgeek\Example.java:[1,2] illegal character: \191
Those character codes (\187 \191) may look a little familiar to some people, as they represent the Byte Order Mark (BOM) that prefixes a UTF-8 formatted file. If you look at them in a file editor (or text editor that doesn’t interpret UTF-8) they will look odd.
They look like “an i (two dots over), double right arrow, upside down question mark”.
Simple solution is to re-edit and save the file as ISO-8859-1.
An alternate approach that is available in some instances is to use the arguments to javac to allow the file encoding.