the new 5.0 tomcat and it's better then the last
version (much faster on my machine) . It still
compiles down a jsp to a single class file with a
single method however.
So why don't you implement that? Tomcat is open
source after all.
If only I were an insominaic with no friends. Then I would have plenty of time to get stuff done.
Hi,
I have read all the answers in this thread, and it really help me fix my problem...to an extent.
I know it is kinda late, and noone may even see my post...but i am very optimistic ;-)
Sometime back, I ran into the same problem too. We had JSP pages for our prototype, so instead of having loops to show the data as we get it from the server, we just hard coded all the values, and so of course, creating a lot of html tags (we used Struts html tag library). and, of course, we got this error. We could fix it by deleting some of the rows of static data, and using loops later on to get the data dynamically.
I understand, that if I use <logic:iterate..> or some kinda logic to show the rows, the class size will decrease??? is that right??
and what would happen when we dynamically get the data at runtime???
As I said, I am optimistic, and would really hope someone reads this and answers
(pleeeeaaasee.....!!!) ;-)
hi Chander,
your tip on using the environment system property helped. But I would like to know what exactly that is doing? or where it is used.
I searched all over the internet...including the Java Sun website, IBM, and others. But didnt come up with anything.
So, if you can please let me know what it does or point me somewhere I can find it, I would really appreciate it.
Is this option com.sun.tools.javac.main.largebranch is
the standard JVM/ JAVAC
option, as i don't seem to find anywhere except on IBM
site.
IS this ibm's proprietary implementation.
Any pointers?
Anything that starts with "com.sun." is specific to Sun.
There are many properties in the Sun JVM that are not documented. Websphere runs in a JVM, any JVM, and the google reference you site is a bug report about the use of that property.
i have some followup questions though, can u pl answer them
(a) so what u r saying is that if JAVA VM is brought up with this property
then the 64k problem get resolved for jsps?
(b) has anybody tried this in other jspcontainers for ex : in tomcat ?
(c) Is this a JVM /JAVAC option ? , why i am asking is one of my colleague went through the
src code for both jdk1.3* and jdk1.4* src code and he could not find the reference
of this properity anywhere.
(a) so what u r saying is that if JAVA VM is
is brought up with this property
then the 64k problem get resolved for jsps?
No idea.
(b) has anybody tried this in other jspcontainers
rs for ex : in tomcat ?
No idea.
(c) Is this a JVM /JAVAC option ? , why i am asking is one of my colleague went through the
src code for both jdk1.3* and jdk1.4* src code and he could not find the reference
of this properity anywhere.
It would be a JVM option.
It might not actually be in there. Or the above references might be mis-naming it. Or it only existed in one version.
Just doing a string search isn't necessarily going to demonstrate that it isn't in there though.
This is actually a bit curious. I'm not an expert on this; this is after half an hour's doc digging; take it with a grain of salt, etc:
One thing that can cause trouble is the size of a string pool in a class file. You have 65535 bytes of string and that's it. If you have one or a couple of text blocks in your JSP, you might write a custom tag that does a kind of a server side include from a separate text file.
But the size of byte code:
In a class file, the size of the byte code of a method is specified with an "u4" - four gigabytes. Ought to be enough.
In the JVM instruction set, branch offsets are specified with two bytes. At least the 1.4.1 "javac" should deal with this automatically: if a method is big, it generates a branch and a jump (a jump offset is four bytes.) (I find no mention of the "largebranch" option in the 1.4.1 javac source.)
Still, various javacs (1.4.2 and 1.5.0beta1) refuse to compile more than 64kB of byte code. 1.4.1 javac compiles, but none of the JVMs I tried (1.4.1, 1.4.2, 1.5.0b1) will run such a method.
There are things in the class file spec that limit the byte code of a method to 64k: exception block offsets, line number offsets, and local variable live range offsets at least are "u2"s (2-byte unsigned ints.) Ouch!
I doubt any amount of compiler options will get you around "code too large". At least some versions of the compiler sort of know how to generate larger code, but the class file format can't handle it.
This is actually a bit curious. I'm not an expert on
this; this is after half an hour's doc digging; take
it with a grain of salt, etc:
One thing that can cause trouble is the size of a
string pool in a class file. You have 65535 bytes of
string and that's it. If you have one or a couple of
text blocks in your JSP, you might write a custom tag
that does a kind of a server side include from a
separate text file.
A single literal is limited to 64k bytes. But there can also be 64k literals.
But the size of byte code:
In a class file, the size of the byte code of a method
is specified with an "u4" - four gigabytes. Ought to
be enough.
No it isn't. Athough more code is allowed for the verifier limits it....
In the JVM instruction set, branch offsets are
specified with two bytes. At least the 1.4.1 "javac"
should deal with this automatically: if a method is
big, it generates a branch and a jump (a jump offset
is four bytes.) (I find no mention of the
"largebranch" option in the 1.4.1 javac source.)
I got the same problem - if I changed all our <html:option> tags to normal <option> tags, I found the problem went away. These shoudl be populated from collections generally, but for us the web developers wanted to be able to affect these dynamically without editing java code, so they were put in the jsp. We coudl have had bunch of this sort of data in the database, but in the end we went for static drop downs. I figure if the <html:options> tag is used instead the problem woudl not arise.
I have hit this problem twice now. The first time I was able to logically split the 'page' into two
pages, one for simple mode, and the other for detailed mode. This way the user sees the page
as seemlessly the same, but all the logic for detailed mode was put in its own JSP file.
The second time I was not so lucky. My pages have NO business logic, but some of them
produce VERY complex HTML with lots of stuff to be switched on and off or handled specially.
The trick I just used to move forward was to use templates:
This was just a quick test, but now I know that it works, I can use it to divide the page up
in a more logical fashion and get some code resuse out of it as well. I was already
using a template to provide a menu on the sidebar for every page, and did not think about
nesting the template tech, but it seems to work just fine.
This topic has
40
replies
on
3
pages.
« Previous |
1
|
2
|
3
|