Tuesday, May 19, 2009

Fast Esp : QRServer and fdispatch not connected

Error code indicates that the channel is not connected. There is no connection between fdispatch and QRServer.

Resolution:


Restart the fdispatch and QRServer processes and then complete the following general debugging procedure:

1. Turn on fnet debugging:
http://:15100/control?debug.fnet=1

2. Issue some queries.

2. Look at the output in qrserver.scrap for output similar to the following:
[2004-01-21 09:33:07] INFO : qrserver->fnet: events[/s][loop/int/io][
967.3/0.0/1.0] packets[/s][r/w][1.0/1.0] data[kB/s][r/w][0.03/0.01]

If you find a packets[/s][r/w][0.0/1.0] message displayed, then the problem
is most likely present on your system (zero packets read per second).

4. Debug logging for RTS and searchctrl. To investigate this further, it is useful to have debug logs from two components. On all search nodes:

etc/searchrc-1.xml
set debuglog="true"

On the configuration server node:
etc/config_data/RTSearch/webcluster/rtsearchrc.xml
set debugLog="true"

5. Edit %FASTSEARCH%/etc/searchrc-dispatch.xml on search nodes with topfdispatch.

set debuglog="true"

By default the option is set to false.

6. Edit the files above accordingly. Shut down the system and restart after verifying that all the processes have terminated successfully (frtsobj.exe, fsearchctrl.exe).

FAST ESP : QRServer timed out

You will get QR server timeout error sometime when you specified the incorrect timeout value in system.

Error:


The exception is: no.fast.ds.search.SearchEngineException: Timed out while waiting for query result.

Resolution:

To resolve this issue, increase the source.xml, fdispatch.addon and fsearch.addon timeout values in the system.

1. Update FASTSEARCH/etc/fdispatch.addon with the following values:
maxdocsumwait = 80
maxsearchwait = 70
maxsocksilent = 120

2. Update FASTSEARCH/etc/fsearch.addon with the following value:
maxsocksilent = 120

3. Update FASTSEARCH/etc/qrserver/sources.xml with the following value:
timeout query="60" docsum="70" (the timeout tag)

4. Restart rtsearch/qrserver.

Handling Query Errors (Java Search API)

Query errors will appear as an exception to the search() method within the ISearchView interface. Instead of printing the full Java exception, it is possible to catch the specific exception with its error code and error message.

Example:

try {
IQueryResult result = engine.(query);
...
...
} catch (SearchEngineException e) {
System.err.println("Error " + e.getMessage() + ": " + e.getErrorCode());
}

A nonzero error code indicates query related error messages.

FAST ESP Adminserver error codes and messages

Adminserver error codes and messages.

Severity:

ERROR

Log message

com.fastsearch.esp.admin.
engine.corba.JacORBNameserviceService
[Nameservice@null:0 Local@null:
/] could not activate ORB
(org.jacorb.orb.ORB@
) : org.omg.CORBA.
INITIALIZE: Could not create server socket
vmcid: 0x0 minor code: 0 completed: No

Cause(s) :

The TCP port that Adminserver's ORB tries to bind to is unavailable.
This is most likely due to another instance of Adminserver running or not properly shut down.

Action(s):

Check if Adminserver is already running. If it is, terminate it and restart Adminserver. Check if some other process has bound to either of the two TCP ports with 'netstat -an'. Make sure no other processes are running in the FAST ESP port range before starting FAST ESP.

FAST ESP Error Messages

The following result format is returned if an error occurs during execution of a query:

XML template:
Could not open channel to server.ERROR>


Text template:

#SEG NAM _SEGNAME_
####
#ERC 1102
#ERT Could not open channel to server.
####


Note:

Error messages in the 10xx range originate from the Search Engine.
Error messages above that originate from the Query & Result Server.




Code Description :

1001 General error. Unexpected internal error message. Contact FAST Technical Support.
1002 Error parsing query. Check the query syntax. Note: When using the FQL query language a query syntax error is normally reported by error message 1201
1003 All partitions are down (Search Engine). Verify installation (System Management) and network interfaces.
1004 No such dataset. A query parameter `dataset' exists but is not supported in this version of the product. Contact FAST Technical Support if this error message appears.
1005 System is overloaded. This will happen when queries are refused due to QPS license limitations.
1006 The requested functionality is not implemented. Check the query syntax and query parameters.
1007 Query not allowed to run (due to internal resource problem). Normally a temporary resource problem - Resubmit query.
1008 Lost connection to one or more Search Engine sub-nodes. Verify installation (System Management) and network interfaces. The search client should normally resubmit the query, refer to Errors related to evaluation of complex queries.
1009 Multiple errors occurred from different search partitions. The search client should normally resubmit the query, refer to section Errors related to evaluation of complex queries.
1010 Query evaluation error (Internal Search Engine error conditions). Contact FAST Technical Support.
1011 Query timeout: One or more Search Engine nodes did not respond within the query timeout limit. The search client should normally resubmit the query, refer to Errors related to evaluation of complex queries.
1012 Not enough resources, query not possible to resolve. Analyze the query that caused the error message. Refer to Errors related to evaluation of complex queries.
1013 Not enough resources, temporary problem within the Search Engine. Search Front End may re-submit. Refer to Errors related to evaluation of complex queries if the error condition always or frequently occurs for specific types of queries.
1014 Not supported - for queries that are not supported. Check query syntax. Contact FAST Technical Support if you are not able to detect errors in the query syntax.
1015 License checkout problem
1016 Requested generation no longer available. A version of the index can no longer be reached. Contact FAST Technical Support.
1020 Document summary internal error. May be a temporary resource problem, Search Front End may try to resubmit query.
1021 Document summary internal error. May also be related to a connectivity problem or search nodes out of operation. Verify installation (System Management) and network interfaces.
1022 Document summary internal error. May also be related to a connectivity problem or search nodes out of operation. Verify installation (System Management) and network interfaces.
1101 No query state supplied, nothing to search for. Contact FAST Technical Support.
1102 Could not open channel to server (No connection to search dispatcher). Verify installation (System Management) and network interfaces.
1103 No query in the query state. Contact FAST Technical Support.
1104 Failed to send query packet. Verify installation (System Management) and network interfaces.
1105 Search timed out. The search client should normally resubmit the query, refer to Errors related to evaluation of complex queries.
1106 Unknown response for query. Contact FAST Technical Support, please include information from query log.
1107 Connection failed while searching (Connection to search dispatcher failed in the query-phase. Verify installation (System Management) and network interfaces.
1108 Failed to send docsum request packet. Verify installation (System Management) and network interfaces.
1109 Docsum fetching timed out (Timed out waiting for docsums from search engine). Refer to Errors related to evaluation of complex queries.
1110 Connection failed while fetching docsums. Verify installation (System Management) and network interfaces.
1111 Unknown response while fetching docsums. Contact FAST Technical Support, please include information from query log.
1112 Failed to store hit information. Contact FAST Technical Support.
1113 Failed to allocate memory for query. Contact FAST Technical Support.
1114 Partial Result. Not possible to retrieve results from all columns (partitions). This may be caused by a connectivity error or an error with a specific search partition. Verify installation (System Management), network interfaces and the status for the search partitions.
1201 FAST Query Language (FQL) query parsing error. Refer to the error text for error details.
1202 Result processor failure. Check query parameters.
1998 Requesting a result template that is not supported. May occur when using customized result template formats.
1999 Query & Result Server error. Contact FAST Technical Support.
2000 Failed to write data to client. (Will only be present in the query logs.) This error is caused by the client closing the connection prematurely.

Wednesday, May 13, 2009

Weblogic 10 Server Compatibility




BEA attempts to support binary and source-level compatibility between the current version of WebLogic Server and all versions as far back as 8.1 in the areas of persistent data, generated classes, and API compatibility. In some cases, it is impossible to avoid incompatibilities. Where incompatibilities arise, they are fully documented in the Upgrading WebLogic Application Environments guide.






Java EE 5 Compatibility


BEA WebLogic Server 10.0 is JEE5 compatible. This compatibility allows a Java EE 5 compliant application to be developed on one operating system platform, and deployed for production on another, without requiring Java EE 5 application code changes. BEA ensures this compatibility of Java EE 5 application portability within a WebLogic Server release level.


Generated Classes Compatibility


With one exception, upgrading to WebLogic Server 10.0 does not require you to recompile applications in order to create new generated classes.


The 10.0 version of the EJBGen utility recognizes only JDK 5.0 metadata annotation-style EJBGen tags and not the old Javadoc-style tags. This means that source files that use the Javadoc-style tags must be upgraded to use the equivalent annotation, and then recompiled using the 10.0 version of EJBGen.


Compatibility Within a Domain



  • All WebLogic Server instances within the same Administrative domain must be at the same major and minor version. You cannot mix server versions within a domain.

  • Servers within an Administrative domain can be at different Service Pack levels as long as the Administration Server is at the same Service Pack. Level or higher than its Managed Servers.

  • All servers within a cluster must be at the same Service Pack level.


JMX Compatibility


See JMX 1.2 Implementation in Upgrading WebLogic Application Environments.


Persistent Data Compatibility


Upgrading to WebLogic Server 10.0 does not require you to make any changes to WebLogic Server 8.1, 9.0, 9.1, or 9.2 persistent data storage, including configuration files, deployment descriptors, transaction logs, and JMS messages.


API Compatibility


WebLogic Server 8.1, 9.0, 9.1, and 9.2 applications deployed on WebLogic Server 9.2 will function without modification. Exceptions to this rule include cases where API behavior was changed in order to conform to a specification or to fix incorrect behavior. In certain circumstances, a correction may cause your application to behave differently.


Protocol Compatibility


Interoperability between WebLogic Server 10.0 and WebLogic Server 8.1, 9.0, 9.1 and 9.2 is supported in the following scenarios:



  • A WebLogic Server 8.1, 9.0, 9.1 or 9.2 client can invoke RMI-based applications hosted on a WebLogic Server 10.0 server using IIOP, T3, T3S, HTTP, and HTTPS. JMS applications can be invoked using T3, T3S, HTTP, and HTTPS.

  • A WebLogic Server 10.0 client can invoke RMI-based applications hosted on a WebLogic Server 8.1, 9.0, 9.1 or 9.2 server using IIOP, T3, T3S, HTTP, and HTTPS. JMS applications can be invoked using T3, T3S, HTTP, and HTTPS.

  • A WebLogic Server 10.0 Web server plug-in can proxy to the latest service pack release of a 8.1, 9.0, 9.1 or 9.2 server.


Interoperability between WebLogic Server 7.0 and WebLogic Server 10.0 is supported in the following scenarios. You will need the WebLogic Server 7.0 patch that is associated with CR295275 for this interoperability to work. This patch is applicable to WLS 7.0 SP6 and WLS 7.0 SP7. You can request this patch by contacting BEA support and requesting the patch associated with CR295275. Additionally, for RMI/IIOP interoperability support, start the WLS 7.0 client using the following flag: -Dweblogic.system.iiop.enableClient=true


  • A WebLogic Server 7.0 client can invoke RMI-based applications hosted on a WebLogic Server 10.0 server using T3, T3S, HTTP, and HTTPS. JMS applications can be invoked using T3, T3S, HTTP, and HTTPS.

  • A WebLogic Server 10.0 client can invoke RMI-based applications hosted on a WebLogic Server 7.0 server using T3, T3S, HTTP, and HTTPS. JMS applications can be invoked using T3, T3S, HTTP, and HTTPS.

  • A WebLogic Server 10.0 Web server plug-in can proxy to the latest service pack release of a 7.0 server.



Java PureFaces : New JSF Framework

Java PureFaces is a layer on top of JSF that simplifies implementation. The article here is the aggregate of the blog posts that I have written on our blog. The framework is not yet made public, and we are looking to see if there is interest in us releasing it as an open-source project. We are not a JSF framework company; we develop web applications. This framework is a result of our experience with the tools with which we were already working.


We are very interested in getting input from the community on it, so please let us know what you think.


Introduction


Developing the Web Tier is a big part of designing and developing a web application. Many frameworks exist that attempt to improve this part of the development. These frameworks simplify the process, providing ready tools and improving code reuse.


Most frameworks are developed around a web designer/Java developer job split, providing a simple API to the web designers, and an XML/HTML file and a Java API for the developers. Examples are Struts and JSF. Other frameworks are aimed only at Java developers and provide a Swing-like API, allowing the developers to develop a web application with only the Java language. The developer code can be very object oriented and does not need to be concerned about interacting with HTTP/ JSP/Tags etc. An example of this type of framework is GWT.


Building off of both of these, we have created a new framework for Java developers that we call Java PureFaces. This framework is built on the very popular JSF framework, but allows the web tier to be designed completely in Java -- no massive library of JSP/JSF pages or configuration files necessary.


Java PureFaces


A little over a year ago, we started looking for a way to create HTML pages without writing HTML code. It did not make sense that a developer that knows a powerful object-oriented language like Java needs to create and maintain static HTML/JSP/XML pages just because of the HTTP protocol. However, JSF is too raw to work with directly (JSF tags, value bindings, etc.).


Java PureFaces provides a pure Java framework for building the web tier. Java developers can use good object oriented solutions, increase code reuse, speed up development, and simplify code maintenance without worrying about many of the web/http concepts like HTTP, JSP, XML, Tags, HTTP sessions, etc. The API is very simple and easy to learn and use.


Like JSF, Java PureFaces binds object attributes into the GUI, and binds commands and link buttons to object methods. Also, JSF components are used to render the HTML. Unlike JSF, Pure JavaFaces attributes and commands can be bound to any POJO object, not only to a backing bean. An advantage of binding to any POJO object through Java is that the bindings themselves can be tested with JUnit.


Because the framework uses JSF, it is very extensible. In order to create a new component, we can extend the UIComponent JSF class. Also, only a single JSP page and backing bean are necessary as the container for the web application (this simplicity does mean that, like some other frameworks, you cannot refresh the page or use the browser back button).


Compare it to a standard JSF application


To quickly illustrate the simplicity of Java PureFaces, we implemented the JSF guessing number game.


Built in the Java PureFaces framework, it makes sense to create two classes: One to represent the logic and one to represent the view. These classes are:



  • GuessNumber -- will know how to create a random number to guess and will check it the user number matches the guessing number.

  • GuessNumberView -- is responsible to create the GUI and response to the button clicks.


Here is the code from the GuessNumberView object:


public class GuessNumberView extends EntryPage implements Serializable {

private static final long serialVersionUID = -7093024622882061259L;

private static final int minNumber = 0;
private static final int maxNumber = 10;
transient private PurePanelGroup component; //not Serializable in the session
private GuessNumber guessNumber;

public GuessNumberView() {
guessNumber = new GuessNumber(minNumber,maxNumber);
}
/**
* pressing on the submit button will create the the response component
*/
public void guessAction() {
createResponseComponent();
}
/**
* pressing on the back button will create the the guess component
*/
public void backAction() {
createGuessComponent();
}
/**
* pressing on the start button will create the the guess component and reset the number
*/
public void startAction() {
createGuessComponent();
guessNumber.start();
}
private void createGuessComponent() {
component = new PurePanelGroup();
component.setFormId("guessForm");
component.add(new PureOutput("Hi. I'm thinking of a number from " + minNumber + " to "
+ maxNumber + " Can you guess it?").setStyleClass("headerText"));
component.add(new PureInput(guessNumber, "userNumber").addValidator(new LongRangeValidator(maxNumber,
minNumber)).setIsRequired(true));
component.add(new PureErrorMessages(true, false, "list").setStyleClass("errorMessage"));
component.add(new PureButton("Submit", this, "guessAction").setStyleClass("button"));
}

private void createResponseComponent() {
component = new PurePanelGroup();
component.setFormId("guessForm");
if (guessNumber.getIsGuessCurrect()) {
component.add(new PureOutput("Yay! You got it!").setStyleClass("headerText"));
component.add(new PureButton("Start", this, "startAction").setStyleClass("button"));
} else {
component.add(new PureOutput("Sorry, " + guessNumber.getUserNumber() + "
is incorrect.").setStyleClass("headerText"));
component.add(new PureButton("Back", this, "backAction").setStyleClass("button"));
}
}
public UIComponent getRootUIComponent() {
if (component == null) {// only for the first time
createGuessComponent();
}
return component.createUIComponent();
}

public String getBackingBeanName() {
return "root";
}
}

Notice that the code to create the simple GUI, as well as the code that handles the button clicks, is cleanly packaged together. Compare this to the JSF Version.


(You can download this demo here: (RAR), (ZIP), (TGZ). There are also full demo applications on the Solutions page of our website. Both of these were created using Java PureFaces)


Clean and Simple Output


So what does the HTML from Java PureFaces look like? Before discussing exactly how the framework works, I want to show how clean it is to work with; I want to show exactly what mark-up is created. I will use a couple of examples from the previous Guess-A-Number demo to show some examples. I'll start by using a single JSP page for the project:


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<html>
<head>
<title>Java PureFaces guessing number demo</title>
<link rel="stylesheet" href='<c:url value="/theme/demoStyle.css" />' type="text/css">
</head>
<body>
<f:view>
<h:panelGroup binding="#{root.render}"></h:panelGroup>
</f:view>
</body>
</html>

This is all that is needed in the simplest application JSP page. The #{root.render} binding is all that is needed to bind the page to the application. Here is the code of the createGuessComponent from the demo:


private void createGuessComponent() {
component = new PurePanelGroup();
component.setFormId("guessForm");
component.add(new PureOutput("Hi. I'm thinking of a number from " + minNumber + " to " +
maxNumber + " Can you guess it?").setStyleClass("headerText"));
component.add(new PureInput(guessNumber, "userNumber").addValidator(new LongRangeValidator(maxNumber,
minNumber)).setIsRequired(true));
component.add(new PureErrorMessages(true, false, "list").setStyleClass("errorMessage"));
component.add(new PureButton("Submit", this, "guessAction").setStyleClass("button"));
}

which creates this simple view:



and this clean HTML (very CSS-friendly):


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Java PureFaces guessing number demo</title>
<link rel="stylesheet" href='/pureFaces-guessNumber/theme/demoStyle.css' type="text/css">
</head>


<body>
<form id="guessForm" name="guessForm" method="post" action="/pureFaces-guessNumber/demo.jsf"
enctype="application/x-www-form-urlencoded">
<span id="guessForm:pureFaces_root1" class="headerText">Hi. I'm thinking of a number from
0 to 10 Can you guess it?</span>


<table cellpadding="0" cellspacing="0" class="__pureFacesErrorGrid">
<tbody>
<tr>
<td><input id="guessForm:pureFaces_root2" name="guessForm:pureFaces_root2"
type="text" value="0" /></td>
<td></td>
</tr>
</tbody>
</table>

<input id="guessForm:pureFaces_root3" name="guessForm:pureFaces_root3" type="submit" value="Submit"
onclick="if(typeof window.clearFormHiddenParams_guessForm!='undefined')
{clearFormHiddenParams_guessForm('guessForm');}if(typeof window.getScrolling!='undefined')
{oamSetHiddenInput('guessForm','autoScroll',getScrolling());}" class="button" />
<input type="hidden" name="guessForm_SUBMIT" value="1" />

</body>
</html>

There is a table in there that is configured to allow for an error message next to the input box through JSF messaging. If the input field is not required, this can be removed for even simpler HTML.


This example shows that when comparing this mark-up to the Java code that created it, you can see it is almost line for line (there is no error message, so it is not rendered). You can use table-based layouts (using PurePanelGrid instead of PurePanelGroup), or work with more current semantic layouts. Either way, it is very easy to create a view. It is also very easy to manipulate the attributes of the HTML elements, like the style classes in the HTML shown here (class=). The framework model can support any element attribute, such as DOM "Level 0 Events (onclick, onkeypress, etc.) and inline styles (style=), to name a few of the more frequently used attributes, by just chaining them onto the component you are adding.


The Way It Works


Now that we have taken a look at the simplicity of the code and the HTML output, I'll describe how we detached the need for a backing bean so that any object or method can be bound to the page.


For a quick review: Typically, JSP pages are coupled with a backing bean, which contains any Java code used in the page. The backing bean must be defined in the faces-config.xml file, and is the page's interface to the rest of the system.


My point here is that:



  • It is tedious to define and maintain the mapping of beans in the faces-config file, and

  • The JSP page is restricted to accessing methods only in the backing bean.


The designer is forced to maintain a JSP file, an XML, and a java class -
for each page in the system (not to mention the navigation mappings, etc).
Java PureFaces removes this complexity and inflexibility. A backing bean is
required, but only one that is used to tie the whole system to a single JSP
page... and this bean is never really used after this. At least, not for binding
to the page. The objects bound to the page are part of the application. The
magic behind Java PureFaces is simple, yet extremely powerful. There is rarely
a need to touch the faces-config file or the JSP page, yet you can bind to
any method or field in the system. Here is how it works.


There are two main things that make Java Pure Faces work. The key to it is that in JSF, listeners are called before the binding.



  • Command Buttons / Links: When you create a command component through the API, Java PureFaces binds that component to the single backing bean using a dummy method that simply returns "success." The work for these components is performed using ActionListeners. First the binding is tested (for testing in JUnit), and then an ActionListener is created from the parameters entered through the API.

  • Inputs: All input types are set up with a default Value Change Listener directed at the desired field entered through the API. Once again, the bindings are tested first using reflection and will throw exceptions for JUnit testing.


That's all there is to it. The listeners are set up to manipulate the target of the component. It is not how JSF was meant to be used, but isn't that where some of the best uses come from? This work is all done behind the scenes, and completely removes the restrictions of the standard JSP/XML/backing bean combination. Absolutely any property can be manipulated, and any method can be triggered. This design enables the system to be completely object-oriented.


As an example to further clarify how useful Java Pure Faces can be, consider a developer who is using Hibernate and would like to bind an entity directly into a view. Using JSF, all backing beans registered in the faces-config file are instantiated at runtime by JSF. Hibernate also instantiates the entities for you. So in this case, the developer cannot do it; an entity cannot be a backing bean. There need to be extra steps to move data from the page to the entity. In Java PureFaces, this is not an issue. The JSP page binds to any POJO in the system through either a Value Change Listener or Action Listener. Hibernate instantiates the entity and anything in that entity can be bound directly into a view.


Object-Oriented API


For the final topic in this article, I want to talk about how Java PureFaces promotes object-oriented programming.


The PureComponent Interface


All Java PureFaces components implement a single interface, PureComponent, that enable them to be used in the framework. This means that, unlike some other frameworks, you do not have to extend a framework-specific object in order to have the functionality of the framwork. In a language that does not allow double-inheritence, being forced to extend another object creates inflexibility. Instead, it allows any object in the application to contain its own display code. It also allows for the creation of custom components that can be easily used throughout the system.


Component Objects


Component creation is very easy with Java PureFaces. All containers, such as PurePanelGrid and PurePanelGroup, take objects that implement PureComponent, and all components are PureComponents. To create a new custom component, you simply implement the interface and then build whatever component you need.


In this example, a simple component - that approximates an HTML label element - is created. By implementing the PureComponent interface, the object is required to implement the createUIComponent method. Inside this method, the component is created from other building blocks. The rest of the object can contain any getters and setters necessary, along with any helper methods, or really just anything at all.


This particular example makes use of another Java PureFaces convenience object called PureEditableValue. This component is a very simple object that holds a reference to a property, and contains the necessary getter and setter needed to access that property. Through the use of generics, that property can be of any type.


public class LabelAndInputComponent<E> implements PureComponent {

private String label;
private PureEditableValue<E> editableValue;
public LabelAndInputComponent(String label, E value) {
this.label = label;
this.editableValue = new PureEditableValue<E>(value);
}
public PureComponent createUIComponent() {
PurePanelGrid panelGroup = new PurePanelGrid(2);
panelGroup.setStyleClass("panelStyleClass");
panelGroup.add(new PureOutput(label).setStyleClass("lableStyleClass"));
panelGroup.add(new PureInput(editableValue).setStyleClass("inputStyleClass"));
return panelGroup;
}
public E getValue(){
return editableValue.getValue();
}
}

This component can now be used anywhere, as shown in the example below. The component is a completely object-oriented solution that can be tested through JUnit. It can extend anything it wants, and of course can implement as many interfaces as necessary. There is absolutely no restriction on making any object a Java PureFaces component.


//.. Some other view object 
private LabelAndInputComponent<String> label = new LabelAndInputComponent<String>("A Label",
"default text"); // example
public PureComponent createUIComponent() {
// Create a DIV element that contains a label component
PurePanelGroup panelGroup = new PurePanelGroup();
panelGroup.setDivStyleClass("divStyleClass");
panelGroup.add(label);
return panelGroup;
}

Easier Maintenance


The final topic to cover is the ease of maintenance for a Java PureFaces implementation. For this, I will use the LabelAndInputComponent implementation that we just discussed.


Testing Java PureFaces is very easy, and very powerful. Of course, it is already easy to test the non-Java PureFaces parts of the object in JUnit the same way we would any other time. The additional advantage here is that we can test the bindings of the Java PureFaces components as well.


The way it works is that the framework tests every binding (using the Reflection API) prior to adding it to the ActionListener or ValueChangeListener. This functionality is done immediately when building the component, and an exception is thrown if something does not check out correctly. Testing the bindings is as simple as:


public void testLabelAndInputComponentImplementation() {
ThatTestObject obj = new ThatTestObject();
obj.createUIComponent();
}

This simple test creates the component and tests that all bindings are valid and able to be resolved.


And finally there is general maintenance. Everything is inside Java. The views are maintained by editing existing objects and components with the ease of whatever development environment you use. There are no JSP files to maintain, there is no XML to update. Productivity is increased by be able to work on all of the code without having to switch gears and use a separate environment. Changes are immediately available when you rebuild the project.

Indexing Issue : excel macro files

PROBLEM
-----------

You found that indexing failed on an excel file with macro with "Password proctected"
error message. While the document is not password protected, we found that certain
parts of the excel document/work sheet are protected and non editable.

RESOLUTION
---------------

Password protected excel files are not supported, as the stellant converter will fail
to process it. In this event, it is normal to receive the error telling you there is
a problem with the documents being password protected or encrypted. In addition,
one will also receive the error if certain parts of the excel document/work sheet are
non editable. The explanation from Stellent on this is that their software cannot
differentiate between various kinds of protections that Microsoft has for Excel
sheets. That is, when a worksheet is being processed, all the converter sees is that
the worksheet has a password protection of some sort. How a worksheet is protected
and what parts of it are protected are not known, because this information is
unavailable to Stellent.

Have a site that recently changed IP, but the crawler is still using an old IP

When the IP is refreshed depends on the Time To Live received from the DNS server.However in crawler versions 6.4.16 and below this behavior was not correct and the dns cache was not updated. The issue is fixed in 6.4.17+, however you can refresh the dns cache the following way:

Stop the crawler and on the ubermaster and the master nodes,

Remove (consider taking a backup) the file

$FASTSEARCH/data/crawler/config/dnscache.hashdb.

Now start the crawler.

The DNS cache should now be reset.

Friday, April 17, 2009

FAST ESP Relevancy Ranking

Relevancy is the measure of how well a set of documents (results) answers or addresses the intent of a given query.


When there are many query matches, the search engines must rank the results by relevance score, sorting the results listing so that the pages most likely to be useful will appear first. Varying algorithms are used to define relevancy. Relevancy definition and tuning is one of core differentiators of FAST ESP platform. This blog post is about the relevance framework and related concepts and features in FAST ESP. 


FAST ESP Search Relevance Framework


FAST ESP applies search relevancy through the following key steps:



  • Data mining – A document processing framework can be used to perform real-time content refinement. This includes embedded relevancy tools and integration points for 3rd party modules. An Entity Extraction framework enables extraction of named entities and key concepts from documents that may be used for result navigation

  • Linguistic normalization – Handles grammatical variations and automatic spell corrections

  • Query Processing – A query processing framework applies built-in or custom query transformations based on application specific rules

  • Ranking based on the FAST InPerspective model provides a multi-faceted measurement of the quality of the match between the query and a candidate result document

  • Query Context Analysis indicates the ability to present the information from the query results in context of the query. FAST ESP supports dynamic document summaries that display the segments of the matching document that provide the most relevant match with the query

  • Data Driven Navigation provides dynamic drill-down into the query result or related areas.

The relevancy of a document with respect to a query is represented by a ranking value. Following section lists the different elements used to calculate the rank value.


Elements of Rank Value



































Element


Description


Freshness


Age of a document compared to the time when the query is issued


Authority


Importance of a document determined by the links to it from other documents


Quality


Assigned importance of a document, independent of the query


Geo


Importance of geographical distance between a document’s associated latitude/longitude and a target location specified in a query


Context


Importance of matching a query in a given document field


Proximity


For multi-term queries: the shorter the distance between query terms in a document, the higher the document’s rank value


Position


The earlier a query term occurs in a field, the higher the document’s rank value


Frequency


The more frequent a query term occurs in a document, the higher the document’s rank value


Completeness


The greater the number of query terms present in the same field of a matching document, the higher the document’s rank value


Number


For multi-term queries; the more query terms matched in a document, the higher the document’s rank value


Relevant Sorting of Query Results


FAST ESP provides three main methods for sorting the results of a query:



  1. Sorting by rank (relevancy score) - FAST ESP computes a rank value based on a set of parameters as described below. These parameters can be tuned in order to provide the best possible perceived relevancy for the end-user. It is possible to define multiple rank profiles that can be selected on a per query basis

  2. Sorting by field values - You may also sort query results by value of any searchable field, such as product name, product code, price or date. FAST ESP supports numeric and full-text sorting, single and multi-level sorting, ascending and descending sorting direction and national sorting rules

  3. Sorting by geographic location - The Geo Search feature provides capabilities for sorting and filtering query results based on geographic location

Rank Profile


A Rank Profile concept enables full control of the relative weight of each rank component for a given query. For example, how important an article’s title is relative to the main text or how important is proximity versus freshness. This enables individual relevance tuning of different query applications using a FAST ESP installation.


In FAST ESP, the Rank Profile is a configuration element within the Index Profile and defines relative weight for the different components of the dynamic rank. Multiple Rank Profiles can be specified in the Index Profile.


Tuning the Ranking and Sorting of Query Results


The ranking and sorting of query results can be tuned in three main ways:



  • Multiple Rank Profiles can be specified in the Index Profile. A Rank Profile defines relative weight for the different components of the dynamic rank

  • Sorting attributes can be specified for individual fields of the documents

  • Result sorting can be controlled on a per query basis. By default the result is sorted by rank as defined in the default Rank Profile. Query parameters enable you to specify an alternative rank profile for the query, or a set of fields that the result shall be sorted by

Relevance support in the Query Language


FAST ESP includes a highly expressive query language that also includes advanced proximity operators:



  • Different relevance weight may be applied to different terms or phrases in a query

  • Explicit proximity (ordered/unordered NEAR) operators enables precise match in semi-structured content without a need for phrase match

  • Boundary match operators enables exact match with extracted entities or entire document elements such as a product name

  • Wildcard query support

Dynamic Client Side Ranking


Dynamic client side ranking can be done by using the XRANK operator which is a part of the FAST Query Language (FQL). The boost value is specified with the parameter boost=n, where n is some signed integer value. Negative boost is supported, but if the result of boosting with a negative value is negative then the result will be set to 0.


Its a concept unique to FAST and I will cover it in detail in another post.


Rank Modification Tools


FAST ESP provides tools to modify rank for individual documents. These tools enable you to perform Absolute Query Boost, Relative Query Boost or Relative Document Boost for given documents in the FAST ESP index. An example could be a product database where it may be desired to boost products with highest profit margins, boost products related to campaigns, etc.


Two main tools exist for this purpose:


1) Search Business Center (SBC) - This is an optional, GUI based tool which enables query-oriented rank tuning. The SBC also includes a powerful query reporting module that may be used to assist in the rank tuning. Using the SBC you can change the ranking for each query using three different methods:



  • Top Ten - to position the document in one of ten reserved places that will be returned at the top of the results list

  • Add boost points - to add a value to a document to increase its relevancy relative to the other documents returned in the search results.You can also add negative boost points to a document.

  • Block from query - to prevent the blocked document from appearing in the search results for the query.

2) Rank Tuning Bulk Loader - This is a standard FAST ESP tool that enables you to perform the same rank tuning as the SBC, using an XML file as input. The XML file contains a specification of the rank modifications to be performed
How SharePoint does Relevancy?

Object Persistence

One of the most critical tasks that applications have to perform is
to save and restore data. Whether it be a word processing application
that saves documents to disk, a utility that remembers its configuration
for next time, or a game that sets aside world domination for the night,
the ability to store data and later retrieve it is a vital one. Without
it, software would be little more effective that the typewriter - users
would have to re-type the data to make further modifications once the
application exits.





Writing the code for saving data, however, can become boring repetitive
work. First, the programmer must create a specification document for the
proposed file structure. Next, the programmer must implement save and
restore functions that convert object data to & from
primitive data types, and test it with sample data. 


If the application later requires new data to be stored, the file
specification must be modified, as well as the save and restore methods. Take it from someone who's been there -
creating save & restore functions is not a fun task.

The solution to this is object serialization.
Object serialization takes an object's state, and converts it to a
stream of data for you. With object serialization, it's an easy task to
take any object, and make it persistent, without writing custom code to
save object member variables. The object can be restored at a later
time, and even a later location. With persistence, we can move an object
from one computer to another, and have it maintain its state. This very
cool feature, in Java, also happens to be very easy to use.

Serializing
objects


Java makes it easy to serialize objects. Any object
whose class implements the java.io.Serializable interface can be made
persistent with only a few lines of code. No extra methods need to be
added to implement the interface, however - the purpose of the interface
is to identify at run-time which classes can be safely serialized, and
which cannot. You, as a programmer, need only add the implements keyword
to your class declaration, to identify your classes as serializable.

public class UserData implements
java.io.Serializable


Now, once a class is serializable, we can write the object to any
OutputStream, such as to disk or a socket connection. To achieve this,
we must first create an instance of java.io.ObjectOutputStream, and pass
the constructor an existing OutputStream instance.

// Write to disk with FileOutputStream
FileOutputStream f_out = new
FileOutputStream("myobject.data");

// Write object with ObjectOutputStream
ObjectOutputStream obj_out = new
ObjectOutputStream (f_out);

// Write object out to disk
obj_out.writeObject ( myObject );


Note that any Java object that implements the serializable interface
can be written to an output stream this way - including those that are
part of the Java API. Furthermore, any objects that are referenced by a serialized
object will also be stored. This means that arrays, vectors, lists, and
collections of objects can be saved in the same fashion - without the
need to manually save each one. This can lead to significant time and
code savings.

Restoring objects from a serialized state


Reading objects back is almost as easy. The one catch is that at
runtime, you can never be completely sure what type of data to expect. A
data stream containing serialized objects may contain a mixture of
different object classes, so you need to explicitly cast an object to a
particular class. If you've never cast an object before, the procedure
is relatively straightforward. First check the object's class, using the
instanceof operator. Then cast to the correct class.

// Read from disk using FileInputStream
FileInputStream f_in = new
FileInputStream("myobject.data");

// Read object using ObjectInputStream
ObjectInputStream obj_in =
new ObjectInputStream (f_in);

// Read an object
Object obj = obj_in.readObject();

if (obj instanceof Vector)
{
// Cast object to a Vector
Vector vec = (Vector) obj;

// Do something with vector....
}

Further issues with serialization


As you can see, it's relatively easy to serialize an object. Whenever
new fields are added to an object, they will be saved automatically,
without requiring modification to your save and restore code. However,
there are some cases where this behavior is not desirable. For example,
a password member variable might not be safe to transmit to third
parties over a network connection, and might need to be left blank. In
this case, the transient keyword can be used. The
transient field indicates that a particular member variable should not
be saved. Though not used often, it's an important keyword to remember.


public class UserSession implements 
java.io.Serializable
{
String username;
transient String password;
}

Summary


Java's support for object serialization makes the implementation of persistent
objects extremely easy. In contrast, the amount of code required to save
and restore every field of an object is complex and repetitive work. While it is certainly possible to write your own
serialization mechanism, the simplicity of that provided by Java would
be hard to beat.

Serialization benefits programmers by


  • Reducing time taken to write code for save and restoration of
    object or application state

  • Eliminating complexity of save and restore operations, and
    avoiding the need for creating a new file format

  • Making it easier for objects to travel over a network connection.


With relatively little effort, you can apply serialization to a
variety of tasks. Not only do applications benefit from serialization,
but also applets. Rather than specifying a long list of parameters, or
performing time consuming initialization and parsing, an applet can
simple reload a configuration object whose member variables contain all
the information needed to execute. It's not just useful for Java applications - even
applets can make benefit, by loading their configuration details or
parameters. With a little imagination, serialization may just have a
place in your next project.

Differnce between C++ and Java

As a C++ programmer, you already have the basic idea of object-oriented programming, and the syntax of Java no doubt looks familiar to you. This makes sense since Java was derived from C++.
However, there are a surprising number of differences between C++ and Java.


These differences are intended to be significant improvements, and if you understand the differences you'll see why Java is such a beneficial programming language. This
article takes you through the important features that distinguish Java from C++.




  1. The biggest potential stumbling block is speed: interpreted Java
    runs in the range of 20 times slower than C. Nothing prevents the
    Java language from being compiled and there are just-in-time
    compilers appearing at this writing that offer significant
    speed-ups. It is not inconceivable that full native compilers will
    appear for the more popular platforms, but without those there are
    classes of problems that will be insoluble with Java because of
    the speed issue.


  2. Java has both kinds of comments like C++ does.


  3. Everything must be in a class. There are no global functions or
    global data. If you want the equivalent of globals, make static
    methods and static data within a class. There are no
    structs or enumerations or unions, only classes.


  4. All method definitions are defined in the body of the class.
    Thus, in C++ it would look like all the functions are inlined, but
    they’re not (inlines are noted later).


  5. Class definitions are roughly the same form in Java as in C++,
    but there’s no closing semicolon. There are no class
    declarations of the form class foo, only class definitions.
    class aType {
    void aMethod( ) { /* method body */ }
    }



  6. There’s no scope resolution operator :: in Java. Java
    uses the dot for everything, but can get away with it since you can
    define elements only within a class. Even the method definitions
    must always occur within a class, so there is no need for scope
    resolution there either. One place where you’ll notice the
    difference is in the calling of static methods: you say ClassName.methodName( );.
    In addition, package names are established using the dot, and
    to perform a kind of C++ #include you use the import
    keyword. For example: import java.awt.*;. (#include
    does not directly map to import, but it has a similar feel to
    it).


  7. Java, like C++, has primitive types for efficient access. In Java,
    these are boolean, char, byte, short, int,
    long, float, and double. All the primitive
    types have specified sizes that are machine independent for
    portability. (This must have some impact on performance, varying
    with the machine.) Type-checking and type requirements are much
    tighter in Java. For example:



    1. Conditional expressions can be only boolean, not integral.



    2. The result of an expression like X + Y must be used; you can’t
    just say "X + Y" for the side effect.


  8. The char type uses the international 16-bit Unicode
    character set, so it can automatically represent most national
    characters.


  9. Static quoted strings are automatically converted into String
    objects. There is no independent static character array string like
    there is in C and C++.


  10. Java adds the triple right shift >>> to act as a
    "logical" right shift by inserting zeroes at the top end;
    the >> inserts the sign bit as it shifts (an
    "arithmetic" shift).


  11. Although they look similar, arrays have a very different structure
    and behavior in Java than they do in C++. There’s a read-only length
    member that tells you how big the array is, and run-time checking
    throws an exception if you go out of bounds. All arrays are created
    on the heap, and you can assign one array to another (the array
    handle is simply copied). The array identifier is a first-class
    object, with all of the methods commonly available to all other
    objects.


  12. All objects of non-primitive types can be created only via new.
    There’s no equivalent to creating non-primitive objects "on
    the stack" as in C++. All primitive types can be created only
    on the stack, without new. There are wrapper classes for all
    primitive classes so that you can create equivalent heap-based
    objects via new. (Arrays of primitives are a special case:
    they can be allocated via aggregate initialization as in C++, or by
    using new.)



  13. No forward declarations are necessary in Java. If you want to use
    a class or a method before it is defined, you simply use it – the
    compiler ensures that the appropriate definition exists. Thus you
    don’t have any of the forward referencing issues that you do in
    C++.


  14. Java has no preprocessor. If you want to use classes in another
    library, you say import and the name of the library. There
    are no preprocessor-like macros.


  15. Java uses packages in place of namespaces. The name issue is taken
    care of by putting everything into a class and by using a facility
    called "packages" that performs the equivalent namespace
    breakup for class names. Packages also collect library components
    under a single library name. You simply import a package and
    the compiler takes care of the rest.


  16. Object handles defined as class members are automatically
    initialized to null. Initialization of primitive class data
    members is guaranteed in Java; if you don’t explicitly initialize
    them they get a default value (a zero or equivalent). You can
    initialize them explicitly, either when you define them in the class
    or in the constructor. The syntax makes more sense than that for
    C++, and is consistent for static and non-static
    members alike. You don’t need to externally define storage for static
    members like you do in C++.


  17. There are no Java pointers in the sense of C and C++. When you
    create an object with new, you get back a reference (which I’ve
    been calling a handle in this book). For example:

    String s = new
    String("howdy");


    However, unlike C++ references that must be initialized when created
    and cannot be rebound to a different location, Java references don’t
    have to be bound at the point of creation. They can also be rebound at
    will, which eliminates part of the need for pointers. The other reason
    for pointers in C and C++ is to be able to point at any place in
    memory whatsoever (which makes them unsafe, which is why Java doesn’t
    support them). Pointers are often seen as an efficient way to move
    through an array of primitive variables; Java arrays allow you to do
    that in a safer fashion. The ultimate solution for pointer problems is
    native methods (discussed in Appendix A). Passing pointers to methods
    isn’t a problem since there are no global functions, only classes,
    and you can pass references to objects.

    The Java language promoters initially said "No pointers!",
    but when many programmers questioned how you can work without
    pointers, the promoters began saying "Restricted pointers."
    You can make up your mind whether it’s "really" a pointer
    or not. In any event, there’s no pointer arithmetic.


  18. Java has constructors that are similar to constructors in C++. You
    get a default constructor if you don’t define one, and if you
    define a non-default constructor, there’s no automatic default
    constructor defined for you, just like in C++. There are no copy
    constructors, since all arguments are passed by reference.


  19. There are no destructors in Java. There is no "scope" of
    a variable per se, to indicate when the object’s lifetime is ended
    – the lifetime of an object is determined instead by the garbage
    collector. There is a finalize( ) method that’s a
    member of each class, something like a C++ destructor, but finalize( )
    is called by the garbage collector and is supposed to be responsible
    only for releasing "resources" (such as open files,
    sockets, ports, URLs, etc). If you need something done at a specific
    point, you must create a special method and call it, not rely upon finalize( ).
    Put another way, all objects in C++ will be (or rather, should be)
    destroyed, but not all objects in Java are garbage collected.
    Because Java doesn’t support destructors, you must be careful to
    create a cleanup method if it’s necessary and to explicitly call
    all the cleanup methods for the base class and member objects in
    your class.


  20. Java has method overloading that works virtually identically to
    C++ function overloading.


  21. Java does not support default arguments.


  22. There’s no goto in Java. The one unconditional jump
    mechanism is the break label or continue label,
    which is used to jump out of the middle of multiply-nested loops.


  23. Java uses a singly-rooted hierarchy, so all objects are ultimately
    inherited from the root class Object. In C++, you can start a
    new inheritance tree anywhere, so you end up with a forest of trees.
    In Java you get a single ultimate hierarchy. This can seem
    restrictive, but it gives a great deal of power since you know that
    every object is guaranteed to have at least the Object
    interface. C++ appears to be the only OO language that does not
    impose a singly rooted hierarchy.


  24. Java has no templates or other implementation of parameterized
    types. There is a set of collections: Vector, Stack,
    and Hashtable that hold Object references, and through
    which you can satisfy your collection needs, but these collections
    are not designed for efficiency like the C++ Standard Template
    Library (STL). The new collections in Java 1.2 are more complete,
    but still don’t have the same kind of efficiency as template implementations would allow.


  25. Garbage collection means memory leaks are much harder to cause in
    Java, but not impossible. (If you make native method calls that
    allocate storage, these are typically not tracked by the garbage
    collector.) However, many memory leaks and resouce leaks can be
    tracked to a badly written finalize( ) or to not
    releasing a resource at the end of the block where it is allocated
    (a place where a destructor would certainly come in handy). The
    garbage collector is a huge improvement over C++, and makes a lot of
    programming problems simply vanish. It might make Java unsuitable
    for solving a small subset of problems that cannot tolerate a
    garbage collector, but the advantage of a garbage collector seems to
    greatly outweigh this potential drawback.


  26. Java has built-in multithreading support. There’s a Thread
    class that you inherit to create a new thread (you override the run( )
    method). Mutual exclusion occurs at the level of objects using the synchronized
    keyword as a type qualifier for methods. Only one thread may use a synchronized
    method of a particular object at any one time. Put another way, when
    a synchronized method is entered, it first "locks"
    the object against any other synchronized method using that
    object and "unlocks" the object only upon exiting the
    method. There are no explicit locks; they happen automatically. You’re
    still responsible for implementing more sophisticated
    synchronization between threads by creating your own
    "monitor" class. Recursive synchronized methods
    work correctly. Time slicing is not guaranteed between equal
    priority threads.


  27. Instead of controlling blocks of declarations like C++ does, the
    access specifiers (public, private, and protected)
    are placed on each definition for each member of a class. Without an
    explicit access specifier, an element defaults to
    "friendly," which means that it is accessible to other
    elements in the same package (equivalent to them all being C++ friends)
    but inaccessible outside the package. The class, and each method
    within the class, has an access specifier to determine whether it’s
    visible outside the file. Sometimes the private keyword is
    used less in Java because "friendly" access is often more
    useful than excluding access from other classes in the same package.
    (However, with multithreading the proper use of private is
    essential.) The Java protected keyword means "accessible
    to inheritors and to others in this package." There is
    no equivalent to the C++ protected keyword that means
    "accessible to inheritors only" (private
    protected
    used to do this, but the use of that keyword pair was
    removed).


  28. Nested classes. In C++, nesting a class is an aid to name hiding
    and code organization (but C++ namespaces eliminate the need for
    name hiding). Java packaging provides the equivalence of namespaces,
    so that isn’t an issue. Java 1.1 has inner classes that
    look just like nested classes. However, an object of an inner class
    secretly keeps a handle to the object of the outer class that was
    involved in the creation of the inner class object. This means that
    the inner class object may access members of the outer class object
    without qualification, as if those members belonged directly to the
    inner class object. This provides a much more elegant solution to
    the problem of callbacks, solved with pointers to members in C++.


  29. Because of inner classes described in the previous point, there
    are no pointers to members in Java.


  30. No inline methods. The Java compiler might decide on its
    own to inline a method, but you don’t have much control over this.
    You can suggest inlining in Java by using the final keyword
    for a method. However, inline functions are only suggestions
    to the C++ compiler as well.


  31. Inheritance in Java has the same effect as in C++, but the syntax
    is different. Java uses the extends keyword to indicate
    inheritance from a base class and the super keyword to
    specify methods to be called in the base class that have the same
    name as the method you’re in. (However, the super keyword
    in Java allows you to access methods only in the parent class, one
    level up in the hierarchy.) Base-class scoping in C++ allows you to
    access methods that are deeper in the hierarchy). The base-class
    constructor is also called using the super keyword. As
    mentioned before, all classes are ultimately automatically inherited
    from Object. There’s no explicit constructor
    initializer list like in C++, but the compiler forces you to perform
    all base-class initialization at the beginning of the constructor
    body and it won’t let you perform these later in the body. Member
    initialization is guaranteed through a combination of automatic
    initialization and exceptions for uninitialized object handles.

    public class Foo extends Bar
    {
    public Foo(String msg) {
    super(msg); // Calls base constructor
    }

    public baz(int i) { // Override
    super.baz(i); // Calls base method
    }
    }





  32. Inheritance in Java doesn’t change the protection level of the
    members in the base class. You cannot specify public, private,
    or protected inheritance in Java, as you can in C++. Also,
    overridden methods in a derived class cannot reduce the access of
    the method in the base class. For example, if a method is public
    in the base class and you override it, your overridden method must
    also be public (the compiler checks for this).


  33. Java provides the interface keyword, which creates the
    equivalent of an abstract base class filled with abstract methods
    and with no data members. This makes a clear distinction between
    something designed to be just an interface and an extension of
    existing functionality via the extends keyword. It’s worth
    noting that the abstract keyword produces a similar effect in
    that you can’t create an object of that class. An abstract
    class may contain abstract methods (although it isn’t
    required to contain any), but it is also able to contain
    implementations, so it is restricted to single inheritance. Together
    with interfaces, this scheme prevents the need for some mechanism
    like virtual base classes in C++.



    To create a version of the interface that can be
    instantiated, use the implements keyword, whose syntax looks
    like inheritance:

    public interface Face {
    public void smile();
    }

    public class Baz extends Bar implements Face {
    public void smile( ) {
    System.out.println("a warm smile");
    }
    }


  34. There’s no virtual keyword in Java because all non-static
    methods always use dynamic binding. In Java, the programmer doesn’t
    have to decide whether to use dynamic binding. The reason virtual
    exists in C++ is so you can leave it off for a slight increase in
    efficiency when you’re tuning for performance (or, put another
    way, "If you don’t use it, you don’t pay for it"),
    which often results in confusion and unpleasant surprises. The final
    keyword provides some latitude for efficiency tuning – it tells
    the compiler that this method cannot be overridden, and thus that it
    may be statically bound (and made inline, thus using the equivalent
    of a C++ non-virtual call). These optimizations are up to the
    compiler.


  35. Java doesn’t provide multiple inheritance (MI), at least not in
    the same sense that C++ does. Like protected, MI seems like a
    good idea but you know you need it only when you are face to face
    with a certain design problem. Since Java uses a singly-rooted
    hierarchy, you’ll probably run into fewer situations in which MI
    is necessary. The interface keyword takes care of combining
    multiple interfaces.


  36. Run-time type identification functionality is quite similar to
    that in C++. To get information about handle X, you can say,
    for example:

    X.getClass().getName();





    To perform a type-safe downcast you say:

    derived d = (derived)base;



    just like an old-style C
    cast. The compiler automatically invokes the dynamic casting mechanism
    without requiring extra syntax. Although this doesn’t have the
    benefit of easy location of casts as in C++ "new casts,"
    Java checks usage and throws exceptions so it won’t allow bad casts
    like C++ does.


  37. Exception handling in Java is different because there are no
    destructors. A finally clause can be added to force execution
    of statements that perform necessary cleanup. All exceptions in Java
    are inherited from the base class Throwable, so you’re
    guaranteed a common interface.

                
    public void f(Obj b) throws IOException {
    myresource mr = b.createResource();
    try {
    mr.UseResource();

    } catch (MyException e) {
    // handle my exception
    } catch (Throwable e) {
    // handle all other exceptions
    } finally {
    mr.dispose(); // special cleanup
    }
    }


  38. Exception specifications in Java are vastly superior to those in
    C++. Instead of the C++ approach of calling a function at run-time
    when the wrong exception is thrown, Java exception specifications
    are checked and enforced at compile-time. In addition, overridden
    methods must conform to the exception specification of the
    base-class version of that method: they can throw the specified
    exceptions or exceptions derived from those. This provides much more
    robust exception-handling code.


  39. Java has method overloading, but no operator overloading. The String
    class does use the + and += operators to concatenate
    strings and String expressions use automatic type conversion,
    but that’s a special built-in case.


  40. The const issues in C++ are avoided in
    Java by convention. You pass only handles to objects and local
    copies are never made for you automatically. If you want the
    equivalent of C++’s pass-by-value, you
    call clone( ) to produce a local copy of the argument
    (although
    the clone( ) mechanism is somewhat poorly designed –
    see Chapter 12). There’s no copy-constructor that’s
    automatically called.



    To create a compile-time constant value, you say, for example:



    static final int SIZE = 255;

    static final int BSIZE = 8 * SIZE;




  41. Because of security issues, programming an "application"
    is quite different from programming an "applet." A
    significant issue is that an applet won’t let you write to disk,
    because that would allow a program downloaded from an unknown
    machine to trash your disk. This changes somewhat with Java 1.1
    digital signing, which allows you to unequivocally know
    everyone that wrote all the programs that have special access to
    your system (one of which might have trashed your disk; you still
    have to figure out which one and what to do about it.). Java 1.2
    also promises more power for applets


  42. Since Java can be too restrictive in some cases, you could be
    prevented from doing important tasks such as directly accessing
    hardware. Java solves this with native methods that allow you
    to call a function written in another language (currently only C and
    C++ are supported). Thus, you can always solve a platform-specific
    problem (in a relatively non-portable fashion, but then that code is
    isolated). Applets cannot call native methods, only applications.


  43. Java has built-in support for comment documentation, so the source
    code file can also contain its own documentation, which is stripped
    out and reformatted into HTML via a separate program. This is a boon
    for documentation maintenance and use.


  44. Java contains standard libraries for solving specific tasks. C++
    relies on non-standard third-party libraries. These tasks include
    (or will soon include):



    • Networking

    • Database Connection (via JDBC)

    • Multithreading

    • Distributed Objects (via RMI and CORBA)

    • Compression

    • Commerce


    The availability and standard nature of these libraries allow for
    more rapid application development.


  45. Java 1.1 includes the Java Beans standard, which is a way to
    create components that can be used in visual programming
    environments. This promotes visual components that can be used under
    all vendor’s development environments. Since you aren’t tied to
    a particular vendor’s design for visual components, this should
    result in greater selection and availability of components. In
    addition, the design for Java Beans is simpler for programmers to
    understand; vendor-specific component frameworks tend to involve a
    steeper learning curve.


  46. If the access to a Java handle fails, an exception is thrown. This
    test doesn’t have to occur right before the use of a handle; the
    Java specification just says that the exception must somehow be
    thrown. Many C++ runtime systems can also throw exceptions for bad
    pointers.


  47. Generally, Java is more robust, via:


    • Object handles initialized to null (a keyword)
    • Handles are always checked and exceptions are thrown for
      failures
    • All array accesses are checked for bounds violations
    • Automatic garbage collection prevents memory leaks
    • Clean, relatively fool-proof exception handling
    • Simple language support for multithreading
    • Bytecode verification of network applets