Re: mina 1.0 and java5
Peter - I noticed that the https://svn.apache.org/repos/asf/directory/branches/mina/1.2 branch still has a bunch of java generics compile warnings. I would like to go ahead and fix these and submit the diff as a patch in JIRA. This sound OK? On 11/5/06, peter royal [EMAIL PROTECTED] wrote: On Oct 30, 2006, at 8:55 PM, peter royal wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. I created a branch for this, https://svn.apache.org/repos/asf/ directory/branches/mina/1.2 (use https://svn.apache.org/viewvc/ directory/branches/mina/1.2 to view) There are also jars available at http://people.apache.org/~proyal/ mina-1.1/ All unit tests pass, and some brief tests in an application of mine look good. Feedback and bug reports welcome! -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
Re: mina 1.0 and java5
On Oct 30, 2006, at 8:55 PM, peter royal wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. I created a branch for this, https://svn.apache.org/repos/asf/ directory/branches/mina/1.2 (use https://svn.apache.org/viewvc/ directory/branches/mina/1.2 to view) There are also jars available at http://people.apache.org/~proyal/ mina-1.1/ All unit tests pass, and some brief tests in an application of mine look good. Feedback and bug reports welcome! -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: mina 1.0 and java5
+1 On 10/31/06, peter royal [EMAIL PROTECTED] wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
Re: mina 1.0 and java5
peter royal wrote: On Oct 31, 2006, at 1:57 PM, Alex Karasulu wrote: i was going to go a bit farther.. replace usage of synchronization with the java5 concurrent data structures (which we could do in 1.4 by using backport more, but i just assume go java5). also update the source to be java5-clean (add @Override, use new for loop, etc). it'd really be a new version. mostly the same, just enhanced for java5 :) Shouldn't this be going into a non-bug fix branch. 1.0 is sealed now in terms of the API. All that should happen are bug fixes with 1.0.x right? Am I missing something here? Yes, this will be a separate branch from 1.0, as to not disturb the 1.0 release. This will be API compatible with 1.0, but no usage of backport, and tweaking internals to make better use of what Java5 offers. Since the trunk has some divergent API changes atm, I thought that a java-5-ized 1.0-api-compatible version would be of use to the community at large while the next big release is baking. What branch would this be? What would be the first release of this be? Asking because we have to avoid confusion with the 1.0.x releases. Alex
Re: mina 1.0 and java5
What time frames are anticipated for the java5 version of mina 1.0? - John On Wed, 2006-11-01 at 07:52 -0800, peter royal wrote: On Nov 1, 2006, at 4:50 AM, Alex Karasulu wrote: What branch would this be? probably 1.2 What would be the first release of this be? probably 1.1 (and both are probably's since no action has happened yet :) Asking because we have to avoid confusion with the 1.0.x releases. understandable.. plan was to bump the minor number in accordance with current policy. just to re-iterate, the only big change would be to use java5, the external API will be source compatible with the 1.0 release. the goal being to give users of 1.0 that also use java5 a java5-optimized build, without having to wait for whatever version the trunk will be, as it has gone down the path of some incompatible API changes (which are fine, just means it will take longer to reach stability and get a release). -pete
Re: mina 1.0 and java5
peter royal wrote: On Nov 1, 2006, at 4:50 AM, Alex Karasulu wrote: What branch would this be? probably 1.2 What would be the first release of this be? probably 1.1 Great this makes lots of sense. There certainly will be no confusion if we take this route. (and both are probably's since no action has happened yet :) Asking because we have to avoid confusion with the 1.0.x releases. understandable.. plan was to bump the minor number in accordance with current policy. Cool I was thinking of creating a mina-core-nobackport-1.0.x which would not be as good as what you have mentioned here with 1.1 and 1.2. just to re-iterate, the only big change would be to use java5, the external API will be source compatible with the 1.0 release. the goal being to give users of 1.0 that also use java5 a java5-optimized build, without having to wait for whatever version the trunk will be, as it has gone down the path of some incompatible API changes (which are fine, just means it will take longer to reach stability and get a release). Thanks for bearing with me as I tried to understand this. +1 Alex
Re: mina 1.0 and java5
Why not simply provide a kind of ant script for fix the sources for 1.5 ? Julien Le lundi 30 octobre 2006 à 20:55 -0800, peter royal a écrit : is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete
Re: mina 1.0 and java5
+1 On 10/31/06, Julien Vermillard [EMAIL PROTECTED] wrote: Why not simply provide a kind of ant script for fix the sources for 1.5 ? Julien Le lundi 30 octobre 2006 à 20:55 -0800, peter royal a écrit : is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete
Re: mina 1.0 and java5
On 10/31/06, Julien Vermillard [EMAIL PROTECTED] wrote: Why not simply provide a kind of ant script for fix the sources for 1.5 ? Good idea; A script that forks instantly, deploys the jar, and wipe the forked source code would be a cleaner option. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
RE: mina 1.0 and java5
A method I've used in the past to switch between backport-util and java5
is to create two sets of subclasses. One set of subclasses inherits
from backport-util, the other from java5. Each set of subclasses exists
in the same package, but the code is kept in distinct source
directories. The rest of the code in the project is written to use
these subclasses. Then I use profiles in the maven pom to select the
best set of subclasses based on the jvm used to build or a property.
A quick search of MINA code shows that there are only 14 classes that
are actually used in backport-util
$ find . -name '*.java' -exec fgrep edu\.emory {} \; | sort | uniq
import edu.emory.mathcs.backport.java.util.concurrent.BlockingQueue;
import edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap;
import
edu.emory.mathcs.backport.java.util.concurrent.CopyOnWriteArrayList;
import edu.emory.mathcs.backport.java.util.concurrent.Executor;
import edu.emory.mathcs.backport.java.util.concurrent.Executors;
import
edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue;
import
edu.emory.mathcs.backport.java.util.concurrent.RejectedExecutionHandler;
import edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue;
import edu.emory.mathcs.backport.java.util.concurrent.ThreadFactory;
import
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor;
import edu.emory.mathcs.backport.java.util.concurrent.TimeUnit;
import
edu.emory.mathcs.backport.java.util.concurrent.atomic.AtomicInteger;
import
edu.emory.mathcs.backport.java.util.concurrent.locks.ReadWriteLock;
import
edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantReadWriteL
ock;
-Original Message-
From: Trustin Lee [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 3:52 AM
To: mina-dev@directory.apache.org; [EMAIL PROTECTED]
Subject: Re: mina 1.0 and java5
On 10/31/06, Julien Vermillard [EMAIL PROTECTED] wrote:
Why not simply provide a kind of ant script for fix the sources for
1.5 ?
Good idea; A script that forks instantly, deploys the jar, and wipe the
forked source code would be a cleaner option.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: mina 1.0 and java5
+1 On 10/31/06, Jeroen Brattinga [EMAIL PROTECTED] wrote: +1 2006/10/31, Trustin Lee [EMAIL PROTECTED]: On 10/31/06, Julien Vermillard [EMAIL PROTECTED] wrote: Why not simply provide a kind of ant script for fix the sources for 1.5 ? Good idea; A script that forks instantly, deploys the jar, and wipe the forked source code would be a cleaner option. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6 -- Jeroen Brattinga
Re: mina 1.0 and java5
On Oct 31, 2006, at 12:14 AM, Julien Vermillard wrote: Why not simply provide a kind of ant script for fix the sources for 1.5 ? i was going to go a bit farther.. replace usage of synchronization with the java5 concurrent data structures (which we could do in 1.4 by using backport more, but i just assume go java5). also update the source to be java5-clean (add @Override, use new for loop, etc). it'd really be a new version. mostly the same, just enhanced for java5 :) -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: mina 1.0 and java5
peter royal wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? I don't understand what this means. Do you mean removing the usage of the backport classes? Right now 1.0 usage requires the use of classes from the edu.emory.mathcs.backport.java.util.concurrent.* packages. You mean to say we make 1.0.x for switch to using java.util.concurrent? Alex
Re: mina 1.0 and java5
peter royal wrote: On Oct 31, 2006, at 12:14 AM, Julien Vermillard wrote: Why not simply provide a kind of ant script for fix the sources for 1.5 ? i was going to go a bit farther.. replace usage of synchronization with the java5 concurrent data structures (which we could do in 1.4 by using backport more, but i just assume go java5). also update the source to be java5-clean (add @Override, use new for loop, etc). it'd really be a new version. mostly the same, just enhanced for java5 :) Shouldn't this be going into a non-bug fix branch. 1.0 is sealed now in terms of the API. All that should happen are bug fixes with 1.0.x right? Am I missing something here? Alex
Re: mina 1.0 and java5
+1 best regards, John On Mon, 2006-10-30 at 20:55 -0800, peter royal wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete
Re: mina 1.0 and java5
On Oct 31, 2006, at 1:57 PM, Alex Karasulu wrote: i was going to go a bit farther.. replace usage of synchronization with the java5 concurrent data structures (which we could do in 1.4 by using backport more, but i just assume go java5). also update the source to be java5-clean (add @Override, use new for loop, etc). it'd really be a new version. mostly the same, just enhanced for java5 :) Shouldn't this be going into a non-bug fix branch. 1.0 is sealed now in terms of the API. All that should happen are bug fixes with 1.0.x right? Am I missing something here? Yes, this will be a separate branch from 1.0, as to not disturb the 1.0 release. This will be API compatible with 1.0, but no usage of backport, and tweaking internals to make better use of what Java5 offers. Since the trunk has some divergent API changes atm, I thought that a java-5-ized 1.0-api-compatible version would be of use to the community at large while the next big release is baking. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: mina 1.0 and java5
+1 Hanson On 10/30/06, peter royal [EMAIL PROTECTED] wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
Re: mina 1.0 and java5
+1 On 10/31/06, peter royal [EMAIL PROTECTED] wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: mina 1.0 and java5
+1 On 10/30/06, Trustin Lee [EMAIL PROTECTED] wrote: +1 On 10/31/06, peter royal [EMAIL PROTECTED] wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: mina 1.0 and java5
+1 Michael Grundvig Electrotank, Inc http://www.electrotank.com - Original Message - From: peter royal [EMAIL PROTECTED] To: mina-dev@directory.apache.org Sent: Monday, October 30, 2006 10:55 PM Subject: mina 1.0 and java5 is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
RE: mina 1.0 and java5
+1 Thanks best regards, Hieu Phan. -Original Message- From: Mike Grundvig [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 12:46 PM To: mina-dev@directory.apache.org Subject: Re: mina 1.0 and java5 +1 Michael Grundvig Electrotank, Inc http://www.electrotank.com - Original Message - From: peter royal [EMAIL PROTECTED] To: mina-dev@directory.apache.org Sent: Monday, October 30, 2006 10:55 PM Subject: mina 1.0 and java5 is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
RE: mina 1.0 and java5
*** Click here to view our e-mail legal notice: http://www.mxit.co.za/pdfs/mxit_legal.pdf or call: +27 21 888 5000 *** +1 -Original Message- From: peter royal [mailto:[EMAIL PROTECTED] Sent: 31 October 2006 06:56 AM To: mina-dev@directory.apache.org Subject: mina 1.0 and java5 is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
RE: mina 1.0 and java5
Definite +1 from me :o) -Original Message- From: Trustin Lee [mailto:[EMAIL PROTECTED] Sent: 31 October 2006 05:31 To: mina-dev@directory.apache.org Subject: Re: mina 1.0 and java5 +1 On 10/31/06, peter royal [EMAIL PROTECTED] wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6 This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: mina 1.0 and java5
On 10/31/06, peter royal [EMAIL PROTECTED] wrote: is there interest in an official mina 1.0 build not requiring the util.concurrent backport? +1 Regards, Vinod.
Re: mina 1.0 and java5
+1 peter royal a écrit : is there interest in an official mina 1.0 build not requiring the util.concurrent backport? this would be slightly more than what can be done by whacking the backport import prefixes.. all data structures that have replacements in j.u.concurrent will be removed and replaced with their jdk-based counterparts. aside from Apache DS using MINA, I get the impression that pretty much everyone else is on java5? -pete
