java speech api

java speech api

Post by Lew » Thu, 20 Nov 2008 03:05:52

"pls" is not a word.

With modern Java, you can wildcard the JARs in the classpath.


Documentation is your friend, focode.


java speech api

Post by ghanoz248 » Thu, 20 Nov 2008 19:32:14

Follow this steps.
1. Go to your java installation directory...
C:\Program Files\Java\

2. Go to JRE installation directory...
C:\Program Files\Java\jre6

3. And then go to lib directory
C:\Program Files\Java\jre6\lib

4. Go to ext directory
C:\Program Files\Java\jre6\lib\ext

5. And the last thing you gotta do is put your jar file on that


java speech api

Post by Sabine Din » Thu, 20 Nov 2008 19:54:25

Oh no, you don't. You shouldn't at least, because it will make it
difficult to distribute your application later.

focode: do you use an IDE? If you use one, you can set your project up
to include libraries, which will then be packaged in the right way.

Actually, you can do this yourself by using ant. Which is what Netbeans
does, anyway ;)

Here's Suns tutorial on packaging your project into jar files:
< ;

You can find ant here:
< ;

java speech api

Post by Lew » Fri, 21 Nov 2008 00:56:21

That is only for a specific purpose, not general deployment of JARs.

For the full story, see "How Classes are Found"
< ;

There are three class paths, for the bootstrap classes, extension classes and
user classes, in that order.

The bootstrap classes are the actual Java platform. The extension classes are
adaptations of the Java node itself, platform-level functionality. The user
classes are those in the application classpaths.

Putting JARs in the extension directory(ies) is analogous to putting DLLs in
the Windows system directory(ies). They become part of the system, in this
case, something like becoming part of the Java language itself. Occasionally
this is what you want, but it harms portability, is inescapable for other
applications if not all apps want those libs, and is usually not necessary.

I've seen issues in practice when an environment lacked extensions that were
assumed by the code, say, those for a non-Sun JVM. Extensions suit well,
OTOH, for JARs that adapt the host environment to look more like a typical
Java host, a conceivable use case, or for focused-purpose nodes where the JVM
is tailored for specific features and not general use.

For general work and to gain maximum ease of deployment, packaging libraries
with the application is usually optimal.