Strange problem with .jar and .class files

[Eric Tonissen]

I have a Java program normal running. I needed some .class files from
another project, builded an .jar file from it, added this to the
classpath and it works.

But now we decided not to use the .class files anymore but to make a
copy from the corresponding sources to my own project.
So I did. But now I have a lot of compile errors about sources which
it also needs ?

I unzipped all the .jars files on the class path, but they are also
not in here.

Is it possible that the compiler includes information into the .class
files, so it doesn't need the other .class files anymore?

 

[Jeff Higgins]

I have a Java program normal running. I needed some .class files from
another project, builded an .jar file from it, added this to the
classpath and it works.

But now we decided not to use the .class files anymore but to make a
copy from the corresponding sources to my own project.
So I did. But now I have a lot of compile errors about sources which
it also needs ?

The third party project you are attempting to build has dependencies
which the compiler cannot resolve is the way I read this so far.

I unzipped all the .jars files on the class path, but they are also
not in here.

You are not able as yet to find the required dependencies.

Is it possible that the compiler includes information into the .class
files, so it doesn't need the other .class files anymore?

No, if I understand the question to be "has the third party packager's
build or packaging process hidden the required dependencies in some
other class file".

You must find the required dependencies and add them to your build and
packaging process.

 

[Lew]

Why? Why?

And there's the "why not".

The third party project you are attempting to build has dependencies which the
compiler cannot resolve is the way I read this so far.


You are not able as yet to find the required dependencies.

And you are not following a good strategy.

No, if I understand the question to be "has the third party packager's build
or packaging process hidden the required dependencies in some other class file".

You must find the required dependencies and add them to your build and
packaging process.

But basically unpacking from a JAR and repacking into a different one is not a
good practice. It defeats the whole point of JARs, and as the OP has found,
opens a world of hurt trying to recapitulate everything that went into the JAR
build. And if the JAR is third party, you really have to watch out for
intellectual property rights. OP, why in the frak are you going down such an
unproductive path?

 

[Jeff Higgins]

Why? Why?

It's a good question, but
I sometimes have difficulty questioning motives right off the bat.
For instance another poster's intent to produce a "human readable" ascii
output of a 10,000 X 10,000 floating point matrix.

 

[Roedy Green]

Is it possible that the compiler includes information into the .class
files, so it doesn't need the other .class files anymore?

static finals can get converted to int or String literals that no
longer reference the original class. That is why you need clean
compiles if you have inter class references of static finals that you
have changed.

The compiler has to be able to see everything referenced, either as
source on the sourcepath or class files on the classpath

 

[Lew]

It's a good question, but
I sometimes have difficulty questioning motives right off the bat.
For instance another poster's intent to produce a "human readable" ascii
output of a 10,000 X 10,000 floating point matrix.

The answer to "why?" informs the answer to "what?"

As Patricia and others often advise posters, tell us the goal, not just your current, possibly flawed idea of implementation. If we know why the OP wants to do such a thing, on the face of it difficult and unrewarding, we might be able to suggest an easy and satisfying way of achieving the goal.

 

[Jeff Higgins]

The answer to "why?" informs the answer to "what?"

As Patricia and others often advise posters, tell us the goal, not just your current, possibly flawed idea of implementation. If we know why the OP wants to do such a thing, on the face of it difficult and unrewarding, we might be able to suggest an easy and satisfying way of achieving the goal.

Good advice.
Perhaps I was reading my own motivations into the OP.
I've had occasion to be dissatisfied with the packaging of "third party"
and even my own code.

I think I may not have precisely understood the process described by the
OP.
Referencing the two paragraphs above.

Beginning with "I have a Java program ...",
I can read this several ways:
a) I snagged some binary class files from another project and packaged
them in a jar,or
b) I built and jar packaged another project using it's own build process,or
c) I built (perhaps a subset) of the classes from another project and
packaged them in a jar.

Beginning with "But now we decided ..."
I suspect here is where the process breaks:
It sounds like:
I am attempting to build (perhaps a subset of) another project using my
own build process.

If I look at for instance Javolution library, their build process
includes a non-standard text substitution step to include or not Java
generics.

 

[Lew]

If I look at for instance Javolution library, their build process includes a
non-standard text substitution step to include or not Java generics.

??!

 

[Jeff Higgins]

??!

A method signature in the .templates.javolution.text package:
public final Appendable/*TextBuilder*/ append(char c)
becomes
public final Appendable<TextBuilder> append(char c)
in the javolution.text package before compilation.

 

[Jeff Higgins]

A method signature in the .templates.javolution.text package:
public final Appendable/*TextBuilder*/ append(char c)
becomes
public final Appendable<TextBuilder> append(char c)
in the javolution.text package before compilation.

or not, depending upon the build parameters.

Which is apropos the OP, if that is your question,
if his process worked when he snagged some binaries
and didn't work when he attempted to build from source.

Which is one imagined scenario from a world of others.

 

[Eric Tonissen]

I have a Java program normal running. I needed some .class files from
another project, builded an .jar file from it, added this to the
classpath and it works.

But now we decided not to use the .class files anymore but to make a
copy from the corresponding sources to my own project.
So I did. But now I have a lot of compile errors about sources which
it also needs ?

I unzipped all the .jars files on the class path, but they are also
not in here.

Is it possible that the compiler includes information into the .class
files, so it doesn't need the other .class files anymore?

We find out that the java used lazy loading of the class-files at
runtime.
So an import of a class is only done when needed.
That's why, when I copied only the sources of the class-files to my
project I got compile errors.
Because these sources has methods which I don't use, but needs sources
which are not available.

Thanks for your help.

 

[Lew]

or not, depending upon the build parameters.

And again I say,

??!

 

[Lew]

We find out that the java used lazy loading of the class-files at
runtime.
So an import of a class is only done when needed.
That's why, when I copied only the sources of the class-files to my
project I got compile errors.
Because these sources has methods which I don't use, but needs sources
which are not available.

Why have you not answered my question? You came here asking for help but
refused to interact with any of us. You didn't even answer a direct question.
What's that all about? Hm?

You do know this is a discussion group and not a help desk, right? And that
interacting with us would have helped you *more*? Hm?

 

[Jeff Higgins]

And again I say,

??!

I don't understand the question(exclamation).

 

[Jeff Higgins]

Why have you not answered my question? You came here asking for help but
refused to interact with any of us. You didn't even answer a direct
question. What's that all about? Hm?

You do know this is a discussion group and not a help desk, right? And
that interacting with us would have helped you *more*? Hm?

The only questions you posed to the OP that I saw were:

"Why? Why?" and
"OP, why in the frak are you going down such an unproductive path?"
both bleated in a reply to one of my posts, not directly to a post by
Eric Tonissen. Maybe he didn't see them. Maybe he chose to ignore them.
After all you did come close to gratuitously impugning his moral
integrity with your parting shot concerning intellectual property rights.

 

[Lew]

I don't understand the question(exclamation).

Fair enough. I'm expressing puzzlement and shock at the idea of pre-processing Java code for generics or not. It seems so bassackwards and unnecessary, though I'm sure they thought they were clever to do this. I might have contented my self with a -target 1.4 (and appropriate bootclasspath) ratherthan manipulating source, presumably to support a ten-year-old version of Java.

Or better, freeze the Java 1.4 library and just freaking use the freaking generics for all current work.

So I was expressing my "WTF?" over their technique.

 

[Lew]

Lew wrote:
"Why? Why?" and
"OP, why in the frak are you going down such an unproductive path?"
both bleated in a reply to one of my posts, not directly to a post by
Eric Tonissen. Maybe he didn't see them. Maybe he chose to ignore them.
After all you did come close to gratuitously impugning his moral
integrity with your parting shot concerning intellectual property rights.

I was cautioning him about IP rights, not impugning. It's a real risk whenyou start cracking JARs. Do you suggest he roll blithely forward if that were an issue? It seems like a reasonable thing to pay attention to when you're lifting source from a third party.

And if he had read the responses to his post, he should have been able to figure out from the position of the question in the flow that my questions were directed to him. After all, that's why we reply in line, isn't it?

And then I explained further why "why?" is an important question. You call that "bleating"?

Sigh.

 

[Arved Sandstrom]

Fair enough. I'm expressing puzzlement and shock at the idea of pre-processing Java code for generics or not. It seems so bassackwards and unnecessary, though I'm sure they thought they were clever to do this. I might have contented my self with a -target 1.4 (and appropriate bootclasspath) rather than manipulating source, presumably to support a ten-year-old version of Java.

Or better, freeze the Java 1.4 library and just freaking use the freaking generics for all current work.

So I was expressing my "WTF?" over their technique.

I'm with you on this one. It occurs to me too that if someone is using
1.5 or higher, there is going to be considerably more than just generics
that get in the way: varargs, annotations, foreach, autoboxing...and the
list continues. Then add in all the API updates, new methods or
interfaces or classes, that might be in use that 1.5 has and 1.4 does not.

I recently had to do some brand new J2SE 1.4 work, not to mention J2EE
1.3 (Servlet 2.3 etc). Blast from the past it wasn't, but it wasn't a
big job fortunately. It's a different world from 1.5+ and like you
suggest it's best to keep codebases that use the one or the other
compartmentalized and different. Otherwise you run the risk of keeping
your 1.5+ stuff stupid...even if you employ nasty tricks like the one
described above.

Mind you, not so long before I also had to do a brief foray into J2SE
1.3 work: don't ask. Imagine my chagrin when I discovered that
String.split() only showed up in 1.4, I'd forgotten all about having to
split strings with indexOf() many, many years ago.

AHS