Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35166 > unrolled thread

How to direct javac to search a jar file?

Back to article view | Back to comp.lang.java.programmer

Contents

  How to direct javac to search a jar file? parmenides <xparmenides@yahoo.com> - 2016-08-02 22:48 +0800
    Re: How to direct javac to search a jar file? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-02 08:11 -0700
    Re: How to direct javac to search a jar file? Nigel Wade <nmw@local.domain> - 2016-08-02 17:50 +0100
      Re: How to direct javac to search a jar file? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-02 10:49 -0700
        Re: How to direct javac to search a jar file? Lew <lewbloch@gmail.com> - 2016-08-02 10:53 -0700
          Re: How to direct javac to search a jar file? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-02 11:11 -0700
            Re: How to direct javac to search a jar file? Lew <lewbloch@gmail.com> - 2016-08-02 13:23 -0700
              Re: How to direct javac to search a jar file? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-03 05:32 -0700
                Re: How to direct javac to search a jar file? Nigel Wade <nmw@local.domain> - 2016-08-03 14:30 +0100
                  Re: How to direct javac to search a jar file? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-03 12:02 -0700
                    Re: How to direct javac to search a jar file? Arne Vajhøj <arne@vajhoej.dk> - 2016-08-03 19:34 -0400
                    Re: How to direct javac to search a jar file? Nigel Wade <nmw@local.domain> - 2016-08-04 14:22 +0100
                Re: How to direct javac to search a jar file? Arne Vajhøj <arne@vajhoej.dk> - 2016-08-03 21:25 -0400
                Re: How to direct javac to search a jar file? Lew <lewbloch@gmail.com> - 2016-08-05 15:31 -0700

#35166 — How to direct javac to search a jar file?

Hi,

    I'm learning how to write servlet. There is an example like this:

package home.parmenides;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Hello extends HttpServlet{
    public void init(ServletConfig config) throws ServletException{
       super.init(config);
    }
    public void service(HttpServletRequest reqest,HttpServletResponse 
response) throws IOException{
       response.setContentType("text/html;charset=utf-8");
       PrintWriter out=response.getWriter();
       out.println("<html><body>");
       out.println("<h2>Welcome to servlet。</h2>");
       out.println("</body></html>");
    }
}

Now that packages of servlet are imported. According to the tutorial, 
these packages are archived in the C:\Tomcat 9.0\lib\servlet-api.jar, 
and it is necessary to copy the file to a JDK directory, namely 
C:\java\jre\lib. This works indeed. But, I think it is more convenience 
to let javac to find the file rather than copying file. I added the 
following path into the classpath:
                C:\Tomcat 9.0\lib
But, javac can not find the servlet-api.jar. How can I deal with the 
problem? Thanks.

[toc] | [next] | [standalone]

#35167

On Tuesday, August 2, 2016 at 10:48:52 AM UTC-4, parmenides wrote:
> Hi,
> 
>     I'm learning how to write servlet. There is an example like this:
> 
> package home.parmenides;
> import java.io.*;
> import javax.servlet.*;
> import javax.servlet.http.*;
> public class Hello extends HttpServlet{
>     public void init(ServletConfig config) throws ServletException{
>        super.init(config);
>     }
>     public void service(HttpServletRequest reqest,HttpServletResponse 
> response) throws IOException{
>        response.setContentType("text/html;charset=utf-8");
>        PrintWriter out=response.getWriter();
>        out.println("<html><body>");
>        out.println("<h2>Welcome to servlet。</h2>");
>        out.println("</body></html>");
>     }
> }
> 
> Now that packages of servlet are imported. According to the tutorial, 
> these packages are archived in the C:\Tomcat 9.0\lib\servlet-api.jar, 
> and it is necessary to copy the file to a JDK directory, namely 
> C:\java\jre\lib. This works indeed. But, I think it is more convenience 
> to let javac to find the file rather than copying file. I added the 
> following path into the classpath:
>                 C:\Tomcat 9.0\lib
> But, javac can not find the servlet-api.jar. How can I deal with the 
> problem? Thanks.

Include the jar (or folder?) in your classpath.  The -cp parameter.

[toc] | [prev] | [next] | [standalone]

#35168

On 02/08/16 15:48, parmenides wrote:
> Hi,
>
>     I'm learning how to write servlet. There is an example like this:
>
> package home.parmenides;
> import java.io.*;
> import javax.servlet.*;
> import javax.servlet.http.*;
> public class Hello extends HttpServlet{
>     public void init(ServletConfig config) throws ServletException{
>        super.init(config);
>     }
>     public void service(HttpServletRequest reqest,HttpServletResponse response) throws IOException{
>        response.setContentType("text/html;charset=utf-8");
>        PrintWriter out=response.getWriter();
>        out.println("<html><body>");
>        out.println("<h2>Welcome to servlet。</h2>");
>        out.println("</body></html>");
>     }
> }
>
> Now that packages of servlet are imported. According to the tutorial, these packages are archived in the C:\Tomcat 9.0\lib\servlet-api.jar, and it is necessary to copy the file to a JDK directory, namely C:\java\jre\lib. This works indeed. But, I think it is more convenience to let javac to find the file rather than copying file. I added the following path into the classpath:
>                 C:\Tomcat 9.0\lib
> But, javac can not find the servlet-api.jar. How can I deal with the problem? Thanks.

Specifying a folder won't include jar files. A folder in the classpath is used as the root of a tree containing class files.
To include a single jar specify the path to that jar file. To include all jar files in a folder use the syntax <folder>/*, where <folder> is the path to the folder in question.

The required classpath is probably:
javac -cp C:"\Tomcat 9.0\lib\servlet-api.jar";"."

or
javac -cp C:"\Tomcat 9.0\lib\*";"."

if more jar's are needed.
If you specify a classpath for the jar then you need to ensure that you also include the default classpath of ".", the current folder, or classes in the current folder/tree won't be found.

The definitive resource on setting the classpath is the Oracle documentation at:
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html

Note that changing the CLASSPATH environment variable is considered bad. It is global, and affects every Java program you compile, or run.
If you try to keep adding every possible classpath to it which every compilation and execution requires it will become a problem.

[toc] | [prev] | [next] | [standalone]

#35169

On Tuesday, August 2, 2016 at 12:51:08 PM UTC-4, Nigel Wade wrote:
> Specifying a folder won't include jar files. A folder in the classpath is used as the root of a tree containing class files.
> To include a single jar specify the path to that jar file. To include all jar files in a folder use the syntax <folder>/*, where <folder> is the path to the folder in question.
> 

ok, I thought I remembered an option for a folder, which I thought should include all jars in a folder.  I think I tried that once and it didn't work so rather than reading about that I just changed my classpath to specifically reference every jar in the folder.  I use Eclipse compile so I don't call javac directly so I've never needed individual class files.  I use the javaw -cp to run some stuff with custom paths.

[toc] | [prev] | [next] | [standalone]

#35170

On Tuesday, August 2, 2016 at 10:50:32 AM UTC-7, Eric Douglas wrote:
> On Tuesday, August 2, 2016 at 12:51:08 PM UTC-4, Nigel Wade wrote:
> > Specifying a folder won't include jar files. A folder in the classpath is used as the root of a tree containing class files.
> > To include a single jar specify the path to that jar file. To include all jar files in a folder use the syntax <folder>/*, where <folder> is the path to the folder in question.
> > 
> 
> ok, I thought I remembered an option for a folder, which I thought should include all jars in a folder.  I think I tried that once and it didn't work so rather than reading about that I just 

That's what the docs are so very useful for.

> changed my classpath to specifically reference every jar in the folder.  I use Eclipse compile so I don't call javac directly so I've never needed individual class files.  I use the javaw -cp to run some stuff with custom paths.

You can substitute "unix" for "windows" in the link Nigel Wade gave for the colon-separated syntax.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#35172

On Tuesday, August 2, 2016 at 1:53:53 PM UTC-4, Lew wrote:
> That's what the docs are so very useful for.

Docs are a waste of time if you know an immediate alternative that does work.
In this case it was an actual waste of time because the -cp folder is not supposed to find jars, so my alternative was correct.

[toc] | [prev] | [next] | [standalone]

#35174

On Tuesday, August 2, 2016 at 11:11:40 AM UTC-7, Eric Douglas wrote:
> On Tuesday, August 2, 2016 at 1:53:53 PM UTC-4, Lew wrote:
> > That's what the docs are so very useful for.
> 
> Docs are a waste of time if you know an immediate alternative that does work.
> In this case it was an actual waste of time because the -cp folder is not supposed to find jars, so my alternative was correct.

If you had read the docs, you would have seen that the folder approach would work with two additional characters in the classpath spec. I never said your alternative is incorrect, but I will say that to declare "[d]ocs are a waste of time" is not correct. Ignorance may be bliss for you, but not for the people who depend on your work.

If you have a lot of JARs to put in your classpath, and you aren't using Maven or some such tool but specifying the classpath yourself, then the long classpath can be tricky to maintain. It isn't incorrect, any more than any other programming technique that works, but it might not be optimal. If you are in the habit of studying and knowing what you are doing, then you increase the likelihood of having an optimal or at least better solution. If you are not in the habit of knowing what you are doing, then you had better be in the habit of being very, very lucky.

If you think "docs are a waste of time", then you are unlikely to be one who knows what you're doing.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#35183

On Tuesday, August 2, 2016 at 4:23:34 PM UTC-4, Lew wrote:
> If you had read the docs, you would have seen that the folder approach would work with two additional characters in the classpath spec. I never said your alternative is incorrect, but I will say that to declare "[d]ocs are a waste of time" is not correct. Ignorance may be bliss for you, but not for the people who depend on your work.
> 
> If you have a lot of JARs to put in your classpath, and you aren't using Maven or some such tool but specifying the classpath yourself, then the long classpath can be tricky to maintain. It isn't incorrect, any more than any other programming technique that works, but it might not be optimal. If you are in the habit of studying and knowing what you are doing, then you increase the likelihood of having an optimal or at least better solution. If you are not in the habit of knowing what you are doing, then you had better be in the habit of being very, very lucky.
> 
> If you think "docs are a waste of time", then you are unlikely to be one who knows what you're doing.

So you're saying Nigel is a liar and you can put jars in a classpath using a folder reference?

Yes ignorance is bliss if you can get something to work properly without wasting time on research that could be better spent on more development, though we all know ignorance can be dangerous if you get code that doesn't crash but actually doesn't do what it's supposed to so no one realizes it's wrong.

My long classpath is not hard to maintain because it doesn't change much and I'm the only one changing it, and in that particular instance I was setting up a set of jars to test an app that would not need updating.

Please respond if you have something helpful to add, not if you're just trying to insult people, act superior, and say you do things other people don't do so they're wrong.  Your tone is horrible, you sound like someone that no one would want to know.

[toc] | [prev] | [next] | [standalone]

#35184

On 03/08/16 13:32, Eric Douglas wrote:
> So you're saying Nigel is a liar and you can put jars in a classpath using a folder reference?

He's not saying that at all. He's saying that there is a better solution than your solution of explicitly listing every jar on the classpath.
If you'd taken the trouble to read the documentation instead of dismissing it as a wast of time, you'd know what it was.

[toc] | [prev] | [next] | [standalone]

#35185

On Tuesday, August 2, 2016 at 4:23:34 PM UTC-4, Lew wrote:
> If you had read the docs, you would have seen that the folder approach would work with two additional characters in the classpath spec.

What additional characters?

On Wednesday, August 3, 2016 at 9:31:02 AM UTC-4, Nigel Wade wrote:
> On 03/08/16 13:32, Eric Douglas wrote:
> > So you're saying Nigel is a liar and you can put jars in a classpath using a folder reference?
> 
> He's not saying that at all. He's saying that there is a better solution than your solution of explicitly listing every jar on the classpath.
> If you'd taken the trouble to read the documentation instead of dismissing it as a wast of time, you'd know what it was.

I did read the docs.  It said folders work, which you just said don't work, and I didn't see "additional characters" in there.  If you were wrong, or at least unclear, just clarify instead of trying to be insulting.

C:\Program Files\Java\jdk1.8.0_102\bin>javac
Usage: javac <options> <source files>
where possible options include:
  -g                         Generate all debugging info
  -g:none                    Generate no debugging info
  -g:{lines,vars,source}     Generate only some debugging info
  -nowarn                    Generate no warnings
  -verbose                   Output messages about what the compiler is doing
  -deprecation               Output source locations where deprecated APIs are u
sed
  -classpath <path>          Specify where to find user class files and annotati
on processors
  -cp <path>                 Specify where to find user class files and annotati
on processors
  -sourcepath <path>         Specify where to find input source files
  -bootclasspath <path>      Override location of bootstrap class files
  -extdirs <dirs>            Override location of installed extensions
  -endorseddirs <dirs>       Override location of endorsed standards path
  -proc:{none,only}          Control whether annotation processing and/or compil
ation is done.
  -processor <class1>[,<class2>,<class3>...] Names of the annotation processors
to run; bypasses default discovery process
  -processorpath <path>      Specify where to find annotation processors
  -parameters                Generate metadata for reflection on method paramete
rs
  -d <directory>             Specify where to place generated class files
  -s <directory>             Specify where to place generated source files
  -h <directory>             Specify where to place generated native header file
s
  -implicit:{none,class}     Specify whether or not to generate class files for
implicitly referenced files
  -encoding <encoding>       Specify character encoding used by source files
  -source <release>          Provide source compatibility with specified release

  -target <release>          Generate class files for specific VM version
  -profile <profile>         Check that API used is available in the specified p
rofile
  -version                   Version information
  -help                      Print a synopsis of standard options
  -Akey[=value]              Options to pass to annotation processors
  -X                         Print a synopsis of nonstandard options
  -J<flag>                   Pass <flag> directly to the runtime system
  -Werror                    Terminate compilation if warnings occur
  @<filename>                Read options and filenames from file

C:\Program Files\Java\jdk1.8.0_102\bin>java
Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)
where options include:
    -d32          use a 32-bit data model if available
    -d64          use a 64-bit data model if available
    -server       to select the "server" VM
                  The default VM is server.

    -cp <class search path of directories and zip/jar files>
    -classpath <class search path of directories and zip/jar files>
                  A ; separated list of directories, JAR archives,
                  and ZIP archives to search for class files.
    -D<name>=<value>
                  set a system property
    -verbose:[class|gc|jni]
                  enable verbose output
    -version      print product version and exit
    -version:<value>
                  Warning: this feature is deprecated and will be removed
                  in a future release.
                  require the specified version to run
    -showversion  print product version and continue
    -jre-restrict-search | -no-jre-restrict-search
                  Warning: this feature is deprecated and will be removed
                  in a future release.
                  include/exclude user private JREs in the version search
    -? -help      print this help message
    -X            print help on non-standard options
    -ea[:<packagename>...|:<classname>]
    -enableassertions[:<packagename>...|:<classname>]
                  enable assertions with specified granularity
    -da[:<packagename>...|:<classname>]
    -disableassertions[:<packagename>...|:<classname>]
                  disable assertions with specified granularity
    -esa | -enablesystemassertions
                  enable system assertions
    -dsa | -disablesystemassertions
                  disable system assertions
    -agentlib:<libname>[=<options>]
                  load native agent library <libname>, e.g. -agentlib:hprof
                  see also, -agentlib:jdwp=help and -agentlib:hprof=help
    -agentpath:<pathname>[=<options>]
                  load native agent library by full pathname
    -javaagent:<jarpath>[=<options>]
                  load Java programming language agent, see java.lang.instrument

    -splash:<imagepath>
                  show splash screen with specified image
See http://www.oracle.com/technetwork/java/javase/documentation/index.html for more details.

[toc] | [prev] | [next] | [standalone]

#35186

On 8/3/2016 3:02 PM, Eric Douglas wrote:
> On Tuesday, August 2, 2016 at 4:23:34 PM UTC-4, Lew wrote:
>> If you had read the docs, you would have seen that the folder
>> approach would work with two additional characters in the classpath spec.
>
> What additional characters?
>
> On Wednesday, August 3, 2016 at 9:31:02 AM UTC-4, Nigel Wade wrote:
>> On 03/08/16 13:32, Eric Douglas wrote:
>>> So you're saying Nigel is a liar and you can put jars in a classpath using a folder reference?
>>
>> He's not saying that at all. He's saying that there is a better
> solution than your solution of explicitly listing every jar on the
> classpath.
> If you'd taken the trouble to read the documentation instead of
> dismissing it as a wast of time, you'd know what it was.
>
> I did read the docs. It said folders work, which you just said don't
> work, and I didn't see "additional characters" in there. If you were
> wrong, or at least unclear, just clarify instead of trying to be insulting.

Not wanting to read docs is not popular.

> C:\Program Files\Java\jdk1.8.0_102\bin>javac
> Usage: javac <options> <source files>
> where possible options include:

That is not really documentation.

> C:\Program Files\Java\jdk1.8.0_102\bin>java
> Usage: java [-options] class [args...]
>            (to execute a class)
>    or  java [-options] -jar jarfile [args...]
>            (to execute a jar file)
> where options include:

> See http://www.oracle.com/technetwork/java/javase/documentation/index.html for more details.

That is documentation.

That link should lead you to:
 
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html#A1100762

Arne

[toc] | [prev] | [next] | [standalone]

#35192

On 03/08/16 20:02, Eric Douglas wrote:

> On Wednesday, August 3, 2016 at 9:31:02 AM UTC-4, Nigel Wade wrote:
>> On 03/08/16 13:32, Eric Douglas wrote:
>>> So you're saying Nigel is a liar and you can put jars in a classpath using a folder reference?
>>
>> He's not saying that at all. He's saying that there is a better solution than your solution of explicitly listing every jar on the classpath.
>> If you'd taken the trouble to read the documentation instead of dismissing it as a wast of time, you'd know what it was.
>
> I did read the docs.

and you still don't know how to specify the classpath correctly?

> It said folders work, which you just said don't work,

you seem to be confused. No one has said that folders don't work. Just that the way you said how to do it was wrong.

> and I didn't see "additional characters" in there.  If you were wrong, or at least unclear, just clarify

The information I provided was correct, and explicit.

> instead of trying to be insulting.

If I wished to be insulting I wouldn't just try.

However, there is nothing which either I or Lew has said which was insulting.
We merely chastised you for your assertion that reading documentation is a waste of time, whilst at the same time providing incorrect information which, had you read the documentation, you should have know was incorrect.

[toc] | [prev] | [next] | [standalone]

#35187

On 8/3/2016 8:32 AM, Eric Douglas wrote:
> Yes ignorance is bliss if you can get something to work properly
> without wasting time on research that could be better spent on more
> development, though we all know ignorance can be dangerous if you get
> code that doesn't crash but actually doesn't do what it's supposed to
> so no one realizes it's wrong.

Functional working is a relative low level of ambition.

Maintainable, efficient etc. usually matters.

And it is difficult to know whether current solution is optimal
without researching options.

> My long classpath is not hard to maintain because it doesn't change
> much and I'm the only one changing it,

So the bus number is zero.

> Please respond if you have something helpful to add, not if you're
> just trying to insult people, act superior, and say you do things
> other people don't do so they're wrong.  Your tone is horrible, you
> sound like someone that no one would want to know.

Suggesting to read documentation is good advice.

Arne

[toc] | [prev] | [next] | [standalone]

#35215

Eric Douglas wrote:
> Please respond if you have something helpful to add, not if you're just trying to insult people, act superior, and say you do things other people don't do so they're wrong.  Your tone is horrible, you sound like someone that no one would want to know.

Your taking refuge in ad hominem attacks is indicative that you have run out of logic and reason to present. No one insulted you, Eric. Now if I were to suggest that you take the bug out of your posterior, you might think that is an insult, although it really would be great advice.

Good night, troll.

-- 
Lew

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web