Hey Mel,
I'll use this as a chance to explain some thoughts
I've recently had on tag pooling. Maybe you and
others have comments.
Mel Martinez wrote:
Hi folks!
I'm still overwhelmed with other priorities (new job,
house-hunting, moving, etc.) to be able to help again,
but I managed
I agree. I spent some time last week looking at possible
optimizations. The general ideas were:
- pool tag handler objects per application. This could
still be turned on/off at runtime via module and is
already available.
- cache (re-use) handlers per page - i.e. only get the handler
from the
Thanks for sending the test application. I've been using monthlist.jsp
while
testing rendered then hand bashed code. After some preliminary bashing :)
I think it will be possible to call all setters (except runtime
expressions)
only once per run of the page. Also, we can create / obtain
[EMAIL PROTECTED] wrote:
Jasper performance is a high priority thing for us (nr 1. on our system
performance fixing list actually), so if possible, absolutely. I can't
say I've delved that far into Jasper yet though. It was a bit hard to
read.
I'm working on a refactoring of jasper,
Hi Costin,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 23, 2001 10:20 AM
...
I'm working on a refactoring of jasper, and easy to read is a big
priority. It's moving a bit slower than I expected - now I'm back on
planning stage after
Rickard,
Thanks for sending the test application. I've been using monthlist.jsp while
testing rendered then hand bashed code. After some preliminary bashing :)
I think it will be possible to call all setters (except runtime expressions)
only once per run of the page. Also, we can create /
[EMAIL PROTECTED] wrote:
We know the pool is synchronized and that may create problems under heavy
load, and we know how to fix this ( by using a per/thread pool without
synchronization ).
That is one solution, but what do you do with the pool after page
request?
I'm not sure I
[EMAIL PROTECTED] wrote:
But in tomcat 3.3 we do a different trick - the thread pool is maintaining
a local storage for each thread, and it's passing it to the worker.
The only synchronization in tomcat is in getting a thread from the thread
pool - besides that we shouldn't need anything
Rickard Öberg wrote:
[EMAIL PROTECTED] wrote:
We know the pool is synchronized and that may create problems under heavy
load, and we know how to fix this ( by using a per/thread pool without
synchronization ).
That is one solution, but what do you do with the pool after page
Glenn Nielsen wrote:
I just had an idea (dangerous things) regarding tag pooling optimizations.
When Jasper translates a page it should be able to generate information
about which tag handler classes it needs, and for each tag handler, the
profile of the attribute/value pairs. At runtime
Glenn Nielsen wrote:
[snip]
I just had an idea (dangerous things) regarding tag pooling optimizations.
When Jasper translates a page it should be able to generate information
about which tag handler classes it needs, and for each tag handler, the
profile of the attribute/value pairs.
On Wed, 23 May 2001, Casey Lucas wrote:
btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff?
Difficult question...
The problem with jasper34 is that it doesn't work yet ( the one in
proposals/jasper34 - I still have to move it in the new repository ). Mea
culpa - I tried
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
On Wed, 23 May 2001, Casey Lucas wrote:
btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff?
Difficult question...
The problem with jasper34 is that it doesn't work yet ( the one in
proposals/jasper34 - I still
On Wed, 23 May 2001, Craig R. McClanahan wrote:
I know Costin loves evolutionary change :-), and it's certainly a valid
approach to Jasper.
But there is also another approach we should consider - a green-field
recoding of at least some of the major components (conforming to an
agreed-upon
Casey,
We hope to freeze 3.3 for a release in the next weeks. If you feel the
changes are reasonably small and will not create problems - you can still
do it.
What about:
1. We copy the code from 3.3 as it is in jasper34 area ( except that we
rename the package ).
2. We make sure it builds
I think the changes will be too big to add before the 3.3 freeze. I like
your alternative and will start bashing the jsp-java files to get something
optimal before changing the jasper34 generator code. I'll let you know when
I have something that looks interesting so that it can be discussed
Hi!
[EMAIL PROTECTED] wrote:
Could you send a small page ( and the taglibs ) and the test conditions ?
I have sent taglib+page and test conditions to Costin.
We know the pool is synchronized and that may create problems under heavy
load, and we know how to fix this ( by using a per/thread
Casey Lucas wrote:
Also, did you run the
tests with and without tag pooling enabled on the same version of
tomcat? (By adding removing TagPoolManagerInterceptor.)
Yes. The only thing changed between the runs was the TPMI flag.
This is a bad design. Basically, any gains you get from
On Tue, 22 May 2001, Rickard Öberg wrote:
Hi!
[EMAIL PROTECTED] wrote:
Could you send a small page ( and the taglibs ) and the test conditions ?
I have sent taglib+page and test conditions to Costin.
Thanks, I'll try to add it to the tests dir.
We know the pool is synchronized and
On Tue, 22 May 2001, Rickard Öberg wrote:
Hash lookup is done once per jsp page - when the jsp page is first run.
After that, it's basically a synchronized push / pop pair on all subsequent
runs of the page. In the future we can even get rid of the synch by using
thread local storage...
Hi Rickard,
Could you send a small page ( and the taglibs ) and the test conditions ?
Most tests I run show a (significant) improvement in performance.
We know the pool is synchronized and that may create problems under heavy
load, and we know how to fix this ( by using a per/thread pool
Rickard,
Can you please send in some complete examples? Also, did you run the
tests with and without tag pooling enabled on the same version of
tomcat? (By adding removing TagPoolManagerInterceptor.)
My experience has been that if the jsp uses many tags, then pooling is
a big performance
-Original Message-
From: Eduardo Pelegri-Llopart [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 19, 2001 12:01 AM
(sorry for the response lag, unfortunatly I don't read tomcat very
frequently)
...
* Using XSTL for templating...
Like Jon and some others, I think that XSTL is
In the case of DoS, I don't believe a bit on trusted tags and such
stuff. Why monitoring the tags at all if while(true) is so easy.
I mean, the front door is wide open, why care about that little
window?
The only way to close everything is by monitoring the Servlets and
allow setting some
Jon Stevens wrote:
on 5/17/01 12:47 PM, Glenn Nielsen [EMAIL PROTECTED] wrote:
But now that both Tomcat 3.2 and Tomcat 4 support the Java SecurityManager
you can control security at the container level regardless of whether someone
is using the CFM servlet, velocity, CoCoon, JSP, etc.
At 07:51 AM 5/18/01, Geir wrote:
Those aren't comparable, 'Velocity templates' and 'general purpose
servlet container', because Velocity is just a template tool - you still
need the servlet and servlet container.
That was exactly my point when I said Velocity doesn't really do anything
to
Dennis Doubleday wrote:
At 07:51 AM 5/18/01, Geir wrote:
Those aren't comparable, 'Velocity templates' and 'general purpose
servlet container', because Velocity is just a template tool - you still
need the servlet and servlet container.
That was exactly my point when I said Velocity
On Fri, 18 May 2001, Paulo Gaspar wrote:
In the case of DoS, I don't believe a bit on trusted tags and such
stuff. Why monitoring the tags at all if while(true) is so easy.
I mean, the front door is wide open, why care about that little
window?
Well, what I said was trusted tags and only
());
#end
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 8:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Jasper performance
Dennis Doubleday wrote:
At 07:51 AM 5/18/01, Geir wrote:
Those aren't comparable, 'Velocity templates' and 'general
It isn't concurrent.
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Jasper performance
Jef Newsom wrote:
Velocity does do a lot to minimize the risk you mention, but while
we're
using
: Friday, May 18, 2001 11:44 AM
To: [EMAIL PROTECTED]
Subject: RE: Jasper performance
It isn't concurrent.
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Jasper performance
Jef Newsom wrote
on 5/18/01 1:37 AM, Paulo Gaspar [EMAIL PROTECTED] wrote:
All Velocity has is a #foreach. This is a fully functional
looping construct
that prevents you from screwing things up and still gets the job done.
On the #foreach and DoS issues, I would use makes it harder instead
of prevents in
on 5/18/01 6:50 AM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Definitely. Agreed. There is no silver bullet.
I guess the point is that you remove a little of the risk, as a designer
can't
% while(true); %
(although as JSP compilers get better, I am sure this stuff can be found
(sorry for the response lag, unfortunatly I don't read tomcat very
frequently)
Hi Jon.
The problem with taglibs is that there is no restriction on the
ability to put Java code in the page. It is part of the JSP
specification to be able to do that. Sure, you can disable it (as
Costin said),
on 5/18/01 3:01 PM, Eduardo Pelegri-Llopart
[EMAIL PROTECTED] wrote:
I didn't see any follow-up clarifying this but apologies if I missed it.
JSP 1.2 has the notion of a TagLibraryValidator that is associated with
a tag library. This can be used to portably validate different
assertions
Sorry, Jon, we disagree. TagLibraryValidators *are* part of the JSP 1.2
specification. They are quite flexible and one of the simplest uses is
to express that some tags cannot appear. Scriptlets are exposed as
jsp:scriptlet tags.
- eduard/o
Jon Stevens wrote:
on 5/18/01 3:01 PM,
on 5/18/01 4:55 PM, Eduardo Pelegri-Llopart
[EMAIL PROTECTED] wrote:
Sorry, Jon, we disagree. TagLibraryValidators *are* part of the JSP 1.2
specification.
Go back and read what I wrote again. I'm not saying that
TagLibraryValidators aren't part of the specification.
They are quite
on 5/18/01 10:48 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Fri, 18 May 2001, Jon Stevens wrote:
Correct, however some bright monkey decided to add % % into the JSP
specification. So, if you disable that, you are breaking the specification.
In other words, it is a bad design in the
...
XSLT is not perfect - neither is HTTP or HTML or any other standard. But
because Apache and many other organizations are implementing and using it
- I think they'll be around for a while :-)
Costin
Costin,
You are still missing the point (as I wrote in my previous post on this
I dont know if I really understood. You (some) are thinking to compile a
jsp using xslt. I didnt know that that was possible. I mean, can a jsp be
loaded as a dom object? I think that it cannot because a nice guy can write
some code like % out.writeln(/html); % and that is, it is not more xml
PROTECTED]]
Sent: 17 May 2001 12:51
To: [EMAIL PROTECTED]
Subject: RE: Jasper performance
I dont know if I really understood. You (some) are
thinking to compile a
jsp using xslt. I didnt know that that was possible. I mean,
can a jsp be
loaded as a dom object? I think that it cannot
At 08:35 PM 5/16/01, Jon wrote:
Also, there is a reason for the #foreach...
http://jakarta.apache.org/velocity/ymtd/ymtd-hosting.html
Jon,
I agree with most of your points. I am a new Velocity user and I am very
impressed by its combination of power and simplicity. Reading/writing XSLT
.
- Chris.
-Original Message-
From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]]
Sent: 17 May 2001 12:51
To: [EMAIL PROTECTED]
Subject: RE: Jasper performance
I dont know if I really understood. You (some) are
thinking to compile a
jsp using xslt. I didnt know
answer inline...
-Original Message-
From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 1:51 PM
I don't know if I really understood. You (some) are thinking
to compile a
jsp using xslt. I didnt know that that was possible. I mean, can a jsp be
and merging the runtime.
Costin
- Chris.
-Original Message-
From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]]
Sent: 17 May 2001 12:51
To: [EMAIL PROTECTED]
Subject: RE: Jasper performance
I dont know if I really understood. You (some) are
thinking
Answer inline:
-Original Message-
From: Christopher Kirk [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 3:17 PM
From my view, the problem with JSP-Java-Class isn't performance its
debugging. JSP is hard to work with when you make a mistake, very
often the
error message
]
Subject: RE: Jasper performance
I agree with you, So I'll suggest you Forte IE, which has a great
debugger.
that allow you to trace exception form the stack to the class,
then to the
original source code.
It also allow break point, which is the least.
The only regrets about this tools
]
Subject: RE: Jasper performance
I dont know if I really understood. You (some) are
thinking to compile a
jsp using xslt. I didnt know that that was possible. I mean,
can a jsp be
loaded as a dom object? I think that it cannot because a nice
guy can write
some code like
Hi Carlos,
On Thu, 17 May 2001, Carlos Gaston Alvarez wrote:
I dont know if I really understood. You (some) are thinking to compile a
jsp using xslt. I didnt know that that was possible. I mean, can a jsp be
loaded as a dom object? I think that it cannot because a nice guy can write
.
Costin
- Chris.
-Original Message-
From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]]
Sent: 17 May 2001 12:51
To: [EMAIL PROTECTED]
Subject: RE: Jasper performance
I dont know if I really understood. You (some) are
thinking to compile a
jsp
On Thu, 17 May 2001 [EMAIL PROTECTED] wrote:
There is another solution - to generate the map ( java line number -
JSP source line number). This is exactly how the .class annotation works,
mapping bytecode to java source number. And will allow you to see both
informations, and it's quite
on 5/17/01 8:01 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Ok Chris. Now I undertand.
Working with JSP when I found that type of mistakes I went to see the .java
generated. There I matched the line number so I could see which was the bad
code. Then I had to go to the jsp to fix it.
It
on 5/17/01 6:46 AM, Dennis Doubleday [EMAIL PROTECTED] wrote:
At 08:35 PM 5/16/01, Jon wrote:
Also, there is a reason for the #foreach...
http://jakarta.apache.org/velocity/ymtd/ymtd-hosting.html
Jon,
I agree with most of your points. I am a new Velocity user and I am very
Christopher Kirk wrote:
From my view, the problem with JSP-Java-Class isn't performance its
debugging. JSP is hard to work with when you make a mistake, very often the
error message is less than helpful. A very large step in improving this is
by making the line number given by the stack
On Thu, 17 May 2001, Paulo Gaspar wrote:
...
XSLT is not perfect - neither is HTTP or HTML or any other standard. But
because Apache and many other organizations are implementing and using it
- I think they'll be around for a while :-)
Costin
Costin,
You are still missing
You should rarely have to worry about mistakes in JSP if you are using tag
libraries and beans to factor out all business logic.
-Original Message-
From: Kaneda K [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 6:55 AM
To: [EMAIL PROTECTED]
Subject: RE: Jasper performance
On Thu, 17 May 2001, Craig R. McClanahan wrote:
On Thu, 17 May 2001 [EMAIL PROTECTED] wrote:
There is another solution - to generate the map ( java line number -
JSP source line number). This is exactly how the .class annotation works,
mapping bytecode to java source number. And
- Chris.
-Original Message-
From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]]
Sent: 17 May 2001 12:51
To: [EMAIL PROTECTED]
Subject: RE: Jasper performance
I dont know if I really understood. You (some) are
thinking to compile a
jsp
On Thu, 17 May 2001, Geir Magnusson Jr. wrote:
Really? I was told that it was a complete myth - that *no one* has to
debug the Java code - they just debug the JSP code. My JSP experience
occurred a few years agoe, and I remember bewildering error messages -
however, I just assumed that was
To: [EMAIL PROTECTED]
Subject: RE: Jasper performance
I dont know if I really understood. You (some) are
thinking to compile a
jsp using xslt. I didnt know that that was possible. I mean,
can a jsp be
loaded as a dom object? I think that it cannot because a nice
guy can write
Jon Stevens wrote:
on 5/17/01 6:46 AM, Dennis Doubleday [EMAIL PROTECTED] wrote:
At 08:35 PM 5/16/01, Jon wrote:
Also, there is a reason for the #foreach...
http://jakarta.apache.org/velocity/ymtd/ymtd-hosting.html
Jon,
I agree with most of your points. I am a new Velocity
Geir Magnusson Jr. wrote:
Christopher Kirk wrote:
From my view, the problem with JSP-Java-Class isn't performance its
debugging. JSP is hard to work with when you make a mistake, very often the
error message is less than helpful. A very large step in improving this is
by making the
Yea, JSP protects you from memory leaks and System Crashes. Yea
Right. Oh yea, and ASP is lacking customizable tags...as if
customizable tags is a good thing
Jihad!
If we're going to open that debate, then why use Java at all? After all, the
computer scientist will tell you with C/C++, you
On Thu, 17 May 2001, Glenn Nielsen wrote:
This is the approach that Tea http://opensource.go.com/ uses as well as
the general idea behind taglibs. The problem with taglibs is that there is
no restriction on the ability to put Java code in the page. It is part of
the JSP specification to
[EMAIL PROTECTED] wrote:
On Thu, 17 May 2001, Glenn Nielsen wrote:
This is the approach that Tea http://opensource.go.com/ uses as well as
the general idea behind taglibs. The problem with taglibs is that there is
no restriction on the ability to put Java code in the page. It is
on 5/17/01 12:47 PM, Glenn Nielsen [EMAIL PROTECTED] wrote:
But now that both Tomcat 3.2 and Tomcat 4 support the Java SecurityManager
you can control security at the container level regardless of whether someone
is using the CFM servlet, velocity, CoCoon, JSP, etc.
Not true.
on 5/17/01 5:21 PM, Glenn Nielsen [EMAIL PROTECTED] wrote:
You won't have much of a templating language if you don't allow some
sort of looping. Kind of hard to restrict that.
All Velocity has is a #foreach. This is a fully functional looping construct
that prevents you from screwing things
on 5/17/01 2:41 PM, Nick Bauman [EMAIL PROTECTED] wrote:
Yea, JSP protects you from memory leaks and System Crashes. Yea
Right. Oh yea, and ASP is lacking customizable tags...as if
customizable tags is a good thing
Jihad!
If we're going to open that debate, then why use Java at all?
On Thu, 17 May 2001, Glenn Nielsen wrote:
I guess he's refering to DOS attacks ( like a while(true); in java code
or allocating lots of memory ).
You won't have much of a templating language if you don't allow some
sort of looping. Kind of hard to restrict that.
True, but if you have a
Ok, I missed the end users.
Chau,
Gaston
- Original Message -
From: Jon Stevens [EMAIL PROTECTED]
To: tomcat-dev [EMAIL PROTECTED]
Sent: Thursday, May 17, 2001 1:26 PM
Subject: Re: Jasper performance
on 5/17/01 8:01 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Ok Chris. Now I
Have you said a Meg of html !!!
Those are the test cases I need.
Chau,
Gaston
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 15, 2001 12:41 PM
Subject: Re: Jasper performance
We use Jasper (from a 3.1 build!) in another container. How big
ps: I am adding also usage options.
- Original Message -
From: Glenn Nielsen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 15, 2001 6:49 AM
Subject: Re: Jasper performance
Jasper performance has already been identified as an area needing
improvement.
Discussions and work
PROTECTED]
Subject: Re: Jasper performance
I would like to propose that the new Jasper require jdk 1.2.
The current version of jasper can be used by those who have jdk 1.1.x.
Then we don't have to worry about jumping through hoops trying to
get the new jasper to run both in 1.1 and 1.2, plus we
Now, people are suggesting using something like XSLT to transform the .jsp
XML/XHTML file into a .java file. Because you are introducing the
XSLT layer
into things, that will have a negative impact on the transformation
performance (I'm not certain how much, but I am pretty much
certain it
On Tue, 15 May 2001, Jon Stevens wrote:
Currently Jasper output's Java code from within Java code. This is about as
fast as you are going to get because there is no intermediate transformation
step going on, just conditional output of String data entirely within Java.
While this is very
on 5/16/01 1:11 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The code generation stage is not significant - compared with the javac
compilation. Some people are even using XSLT at runtime ( not that this is
a good idea ) - so I doubt it'll have such a significant impact on
development mode
On Wed, 16 May 2001, Jon Stevens wrote:
Costin,
Once again, you impress me with your inability to understand a word of what
I'm talking about. So, let me close this discussion with this:
No problem, I'm not that good at explaining either.
If the speed of generating a .java file (or
on 5/16/01 4:02 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Yet another template generation language ??? #foreach ???
Costin, what rock have you been sleeping under for the last 5 years?
Velocity is simply a cleaner implementation of WebMacro. It isn't YATGL.
Also, there is a reason for
On Wed, 16 May 2001, Jon Stevens wrote:
on 5/16/01 4:02 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Yet another template generation language ??? #foreach ???
Costin, what rock have you been sleeping under for the last 5 years?
Velocity is simply a cleaner implementation of WebMacro.
On Wed, 16 May 2001, Jon Stevens wrote:
may? Do you have empirical evidence of that or did you pull that out of
your ass?
I guess that concludes our discussion.
Costin
, and may
end up saving the javac in some cases - which would be a significant speed
improvement.
Ah.
on 5/16/01 7:06 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Wed, 16 May 2001, Jon Stevens wrote:
on 5/16/01 4:02 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Yet another template generation language ??? #foreach ???
Costin, what rock have you been sleeping under for the last 5
Jasper performance has already been identified as an area needing
improvement.
Discussions and work on this has already started in the main tomcat
branch in CVS jakarta-tomcat/proposals/jasper34, but this may be
moving to the CVS repository jakarta-tomcat-jasper.
This work just started
Rickard,
As Glenn mentioned, Jasper is in the process of getting a rework. But in the
mean time and since you mentioned taglibs, you may want to look at the tag
pooling module that was added to tc 3.3. If your jsps use a lot of tags,
you should see a big performance gain. Let me know if you
I, for one, would be very interested in making it easy/possible to uncouple
Jasper from the servlet container itself. The question I have is How much of
a scaffolding is required to use Jasper purely as a template engine without
the baggage of the servlet container per se (or at worst, by being
]
To: [EMAIL PROTECTED]
cc:(bcc: Ken X Horn)
Subject: Re: Jasper performance
Jasper performance has already been identified as an area needing
improvement.
Discussions and work on this has already started in the main tomcat
branch in CVS jakarta-tomcat/proposals/jasper34
[EMAIL PROTECTED] wrote:
We already added tag pooling in tomcat3.3, and that have a significant
effect on performance if you are using tags - but that's just the
beginning.
This is great news! Our other options was to use another engine (like
Orion or Resin), write our own JSP compiler, or
Jon Stevens wrote:
Or you could use another tool that doesn't require you to generate .java
files first, doesn't require a boat load of caching to get decent
performance (imagine that using JSP the right way causes it to
actually run slower???), doesn't need a complete re-write to fix
I would like to propose that the new Jasper require jdk 1.2.
The current version of jasper can be used by those who have jdk 1.1.x.
Then we don't have to worry about jumping through hoops trying to
get the new jasper to run both in 1.1 and 1.2, plus we can optimize
for 1.2. In addition JSP 1.2
On Tue, 15 May 2001, Glenn Nielsen wrote:
I would like to propose that the new Jasper require jdk 1.2.
The current version of jasper can be used by those who have jdk 1.1.x.
Then we don't have to worry about jumping through hoops trying to
get the new jasper to run both in 1.1 and 1.2, plus
on 5/15/01 7:05 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Tue, 15 May 2001, Glenn Nielsen wrote:
I would like to propose that the new Jasper require jdk 1.2.
The current version of jasper can be used by those who have jdk 1.1.x.
Then we don't have to worry about jumping through
On Tue, 15 May 2001, Jon Stevens wrote:
on 5/15/01 7:05 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Tue, 15 May 2001, Glenn Nielsen wrote:
I would like to propose that the new Jasper require jdk 1.2.
The current version of jasper can be used by those who have jdk 1.1.x.
Then
on 5/15/01 8:32 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+1 for the generator.
Considerations on the generator:
This will slow development down even further doing the transformation step.
What ? Using JDK1.2 instead of JDK1.1 ?
I doubt it, but thanks for worrying about this
92 matches
Mail list logo
