During this sort of discussion you may not be able to combine two or
more of my messages, from several hours apart, and parse them together
to get a single coherent position. That won't happen until we have
finished discussing the subject and there is no more input that might
change my mind.
I don't know exactly what you mean by "baseline". To me the key
questions are what is our compilation target, and what versions do we
test against. If we pick release N as compilation target, we should be
able to test with JVM N, N+1, N+2, ... . On the other hand, if we don't
routinely compile targeting N, we won't be able to run on JVM N, because
N-incompatible source code changes will creep in.
I believe that, in order to use the most relevant features of 1.6 we
would have to run with a 1.6 JVM and rt.jar. The question is whether the
gains from going to 1.6, rather than 1.5, are worth the cost.
We know at least some of the cost of compiling to 1.6, abandoning anyone
who is stuck on 1.5.
Now I'm trying to probe the cost of compiling to 1.5, but testing with
both 1.5 and 1.6 JVMs. I understand the cost to River developers,
especially the loss of the 1.6 java.util enhancements - and I think it
is a manageable convenience cost.
Now I'm asking "Does compiling River to 1.5 impose a cost on 1.6 users,
assuming we do QA test against JVM 1.6 as well as JVM 1.5?".
Patricia
Dennis Reedy wrote:
Trying to parse this correctly, let me make sure I understand what you are
saying:
Baseline River on Java 1.6 and have a compile target of 1.5?
If so, how does this relate to your earlier post?
On Dec 2, 2010, at 940AM, Patricia Shanahan wrote:
In my opinion, the differences between 1.5 and 1.6 that would most benefit
River are in java.util and its sub-packages. 1.5 added a good set of
concurrency support. 1.6 improved it based on experience.
The only way I know to get a 1.6 rt.jar is to run with a 1.6 JVM.
IMO, as River moves through it's roadmap, move to JDK to 1.6 when you make the
namespace change. Branch the 2.1.2 version, keep it JDK 1.4. The 2.1.2 branch
will still have the com.sun namepsace. and provide legacy support for those
that need it. If possible (and if needed), make changes to that branch as
changes and bug fixes are made to trunk. If those that are interested and
engaged want to help with that effort, they can certainly become engaged and
help make that happen.
Regards
Dennis
On Dec 2, 2010, at 842PM, Patricia Shanahan wrote:
Would your use of River be adversely affected by a decision to limit River
source code to 1.5 compatible features, compile with target 1.5, and test it
with both 1.5 and 1.6?
Patricia
On 12/2/2010 5:26 PM, Dennis Reedy wrote:
Patricia,
There are many interested and active users. Michael is just one that has
expressed his opinions. I am also one, and have expressed mine (I urge others
on this list to also express their opinions). The systems that I currently work
with (in DoD and beyond) all use River, and all are based on 1.6. I dont see
how moving to a baseline that has its Java Technology End of Life (EOL)
transition period that ended October 8th, 2009 is a good plan for the future of
River.
The JSR1 requirements are easily met by the current distribution of River. We
do not know the future of Oracle's plan with RTSJ. That combined with the
recent post that Thread.interrupt() breaks classloading in 1.5 and that there's
no feasible workaround for River seen, why baseline on a technology that is not
only EOL, but also has known issues?
Dennis
On Dec 2, 2010, at 749PM, Patricia Shanahan wrote:
The way I see it, the really big gain is going to 1.5. That gets us the initial
implementation of the concurrent and atomic classes in java.util.*, and
generics.
Going to 1.6 adds some value, but not as big a step. For example, my
TaskManager rewrite would be a bit simpler with the 1.6 version of
java.util.TreeSet, but I can work around the missing methods.
I would rather give up the 1.6 features that are not in 1.5, at least for now,
than give up an interested, active user.
Patricia
On 12/2/2010 4:17 PM, MICHAEL MCGRADY wrote:
The status of Real Time Java is not a sentimental matter, but an
instructive fact of Sun culture.
The first thing should be to see is where Java 1.6 might be a plus
for River. Can you list these areas? That would be very helpful.
MG
On Dec 2, 2010, at 3:58 PM, Dennis Reedy wrote:
Well all sentimentality aside for JSR 1, I still stick with my
earlier suggestion of:
I would encourage that as River moves along it's roadmap, once the
namespace is changed to org.apache.river, that River mandates 1.6
as a baseline. Migration guides and/or utilities can be provided to
assist in the transition from legacy Jini to River.
Regards
Dennis
On Dec 2, 2010, at 545PM, MICHAEL MCGRADY wrote:
If there is a way to move forward and keep River compatible with
Java 1.5, that would be ideal. We obviously cannot just stand
still even though Java RTS might for a time. It is hard to tell
at this stage what is happening because of the Oracle purchase of
Sun and speculation is not a thing I like to do. However, we do
know that Java RTS is the first Java Community Process, i.e.
literally No. 1, and I cannot believe that Java would abandon
this effort to the dustbin of history. That would not bode well
for Java as a platform.
MG
On Dec 2, 2010, at 2:00 PM, Dennis Reedy wrote:
If you're fine with River 2.1.1 then you have a platform which
you can move forward with right? That release is baselined at
Java 1.4.
As River moves forward with it's roadmap, changing the com.sun
namespace to org.apache, and possibly moving to Java 1.6, you
would still have a platform (2.1.1) that you could use.
As RTJ (hopefully) moves forward with eventual 1.6+
interoperability at that point you could move to River,
including product changes to account for the namespace change
as well.
Does that suffice?
On Dec 2, 2010, at 337PM, MICHAEL MCGRADY wrote:
More on this later, but I am certainly aware that River
cannot stay stagnant at Java 1.5. We need to be realistic
but the real-time Java is going to "hit" in the near term, I
think. There might need to be options and tracks and
whatever makes sense to River.
MG
On Dec 2, 2010, at 10:42 AM, Dennis Reedy wrote:
On Dec 2, 2010, at 127PM, MICHAEL MCGRADY wrote:
Perhaps this will help: on the generic question of going
to Java 1.6, and my plea not to do it.
http://www.devx.com/Java/Article/33475
Michael,
Thanks for the link. You may also find more information
here:
http://java.sun.com/javase/technologies/realtime/faq.jsp
One thing on this topic that I am curious about is what
Oracle's plan is for RTJ. We certainly cant answer that in
this forum. But... will they keep it? If so, and if they
are given a large enough business opportunity for it's use,
will they move towards supporting 1.6? While this is a very
interesting and compelling technical use of River, is it
enough to prohibit River moving to 1.6 and beyond?
Just asking ...
Regards
Dennis
Michael McGrady Chief Architect Topia Technology, Inc. Cel
1.253.720.3365 Work 1.253.572.9712 extension 2037
mmcgr...@topiatechnology.com
Michael McGrady Chief Architect Topia Technology, Inc. Cel
1.253.720.3365 Work 1.253.572.9712 extension 2037
mmcgr...@topiatechnology.com
Michael McGrady Chief Architect Topia Technology, Inc. Cel
1.253.720.3365 Work 1.253.572.9712 extension 2037
mmcgr...@topiatechnology.com
