I've raised a GitHub PR [1] to add the Java 9 module name to [math] on
the MATH_3_X branch. Assuming that is merged, I'm willing to raise
another PR with the necessary bits to prepare the repo to release
v3.6.2.
This approach sidesteps all issues with commons-4 and does the minimum
necessary for d
On Thu, 6 Jun 2019 at 23:21, Gilles Sadowski wrote:
> I was about to merge the PR but, on my machine, the build fails.
> Did you try?
`mvn clean verify` works for me (maven running on Java 7 and on Java 8).
> Back then (pre-fork), I was in favour of maintaining both lines (3.X
> and 4.X); but th
On Fri, 7 Jun 2019 at 15:16, Gilles Sadowski wrote:
> drive such a maintenance/security release.
> If the build process works on your machine, you are a better
> RM candidate. ;-)
Given I haven't committed to commons for 10+ years (at a guess), I'm
not a PMC member and probably don't have permiss
I've started to try and get a release out on the branch to get the
Java module name in. Since I haven't committed in many years this
isn't going to be easy.
I've successfully pushed a small fix directly to the MATH_3_X branch.
I've seen something suggesting that branches can't be deleted, which
ma
en-checkstyle-plugin:3.0.0:check (validate) on
> project commons-rng-parent: You have 10 Checkstyle violations. -> [Help 1]
>
> Can someone please fix those so we can run simple builds from the command
> line?
>
> Gary
>
>
>
> On Mon, Sep 16, 2019 at 1:16 PM seb
en
On Mon, 16 Sep 2019 at 20:08, Stephen Colebourne wrote:
>
> As far as I can tell, mvn site works on the branch with my PR. Shall I merge
> it?
> I wasn't planning on fixing master.
> Stephen
>
>
> On Mon, 16 Sep 2019 at 18:26, Gary Gregory wrote:
> >
> &g
On 16 October 2012 17:44, Matt Benson wrote:
> On Tue, Oct 16, 2012 at 11:42 AM, James Carman
> wrote:
>> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson wrote:
>>>
>>> Are these specific examples not the words you would actually use were
>>> you having a discussion on the subject in English? :P
On 4 December 2012 23:05, Gary Gregory wrote:
> I like the name weaver.
>
> Does it make sense to allow different libs to be plugged in? BCEL,
> ASM... Or do do we have to pick one?
Based on what I see in various projects, ASM won, BCEL lost. Main
problem tends to be different versions of ASM bei
FYI, the Project Lambda Streams code and JSR-310 in JDK 1.8 are both
written with static imports in mind. Moreover, with support for static
methods in interfaces being added, this is likely to increase as a
pattern. Those facts may or may not affect decisions in commons.
Stephen
On 4 February 20
Does commons-logging need to be a full module with a module-info.java?
Probably not at this point. Adding Automatic-Module-Name is probably
sufficient. However, if someone wants to do the work, then adding
module-info shouldn't be blocked IMO.
I don't believe that module-info.java requires Java 6
You'd need https://github.com/apache/commons-lang/pull/304 too for Java 9
Stephen
On 3 November 2017 at 17:36, Gary Gregory wrote:
> Hi All:
>
> I propose we release 3.7 principally to pick up
> https://issues.apache.org/jira/browse/LANG-1365 to support those brave
> souls trying out Java 10 EA.
Frankly, as an observer, this issue seems to be handled pretty poorly.
Commons-Math is currently dead. There are people willing to put in
effort to work on parts of it, but they are blocked at every turn.
Various options are put forward, but nothing ever happens.
In technical terms, if Commons-Mat
; Hi all.
>
> Stephen Colebourne correctly summarized the situation[1]:
> Project management must be based on life-cycle, not the
> other way around.
>
> Here below, a concrete plan is proposed in answer to the
> suggestion (of a fork) made by Martijn Verburg[2].
>
> 1. Initial
Just to note that commons-pool v2.5.0 did not have
Automatic-Module-Name added, which is sad.
Stephen
On 20 December 2017 at 17:31, Gary Gregory wrote:
> Hi All,
>
> Now that Apache Commons Pool 2.5.0 and builds cleanly with Commons DBCP
> master, I'd like to release Commons DBCP 2.2.
>
> I plan
On 28 December 2017 at 19:49, Gary Gregory wrote:
> Hi All,
>
> - BeanUtils now has a new package o.a.c.beanutils2.
> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
> which caused the above.
>
> What more do we want before releasing 2.0.0?
>
> Updating from BU 1.x to 2.x sh
This seems a lot more effort than just adding something to the pom.xml
in the child project.
Stephen
On 9 January 2018 at 12:11, Gilles wrote:
> Hi.
>
> My suggestion would be
> "profile.java_automatic_module_name"
> in the top directory.
>
> Gilles
>
>
> On Mon, 8 Jan 2018 22:23:08 -0800, Chas
On 1 February 2018 at 15:30, Gary Gregory wrote:
> For example, (picking a made up example) this reads really well to me:
> Pair.of(foo, bar) because that what you'd use in spoken English.
>
> OTOH, this does not read well to me: Fraction.of(num, denum); this would be
> better: Fraction.from(num,
Some of the classes you are talking about are what I call VALJOs.
Follow these guidelines and your class will be well placed for the
future.
http://blog.joda.org/2014/03/valjos-value-java-objects.html
Stephen
On 2 February 2018 at 12:45, Gilles wrote:
> On Thu, 1 Feb 2018 08:30:00 -0700, Gary Gre
1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
six-month release which is about to be replaced by Java 10, which will
then be replaced by Java 11. Thus, Java 8 is the only sensible
baseline right now.
2) Compiling a single jar file such that it works on Java 8 but has a
modu
On 7 March 2018 at 18:56, Ralph Goers wrote:
> Actually, you really do need to use a multi-release jar to include a
> module-info class file. Otherwise it may be sitting alongside of classes
> compiled for an earlier java release and various tools will fail because of
> it.
Then those tools ne
Just to note that surefire v2.21.0 is out now. No idea if that helps.
Stephen
On 9 March 2018 at 08:22, Stefan Bodewig wrote:
> Hi all
>
> I wanted to see whether anything was broken in COMPRESS with the Java10
> RC or the EA version of Java11 - unfortunately the build fails with
> NullPointerExc
On 10 June 2018 at 00:02, Bruno P. Kinoshita
wrote:
> Yes, that's my understanding. We would use require static on java.desktop,
> but users wouldn't have any issues as long as they did not use the version of
> the class that requires java.desktop.
>
> If the user want/needs to use those classes
_____From: Benedikt Ritter
>>>
>>> To: Commons Developers List
>>> Sent: Monday, 5 June 2017 10:49 PM
>>> Subject: [LANG] Java 9 problems because of dependencies to java.desktop
>>> (Was: Re: [LANG] Thoughts about Lang
Look at Joda-Convert/Joda-Parent for example. A Java 6 project that
builds on Java 8 or later, and has a module-info.java.
Cobertura just needs replacing with JaCoCo.
FindBugs replaced by SpotBugs
Lots of plugin versions updated.
And lots of profiles, as per Joda-Convert/Joda-Parent
Stephen
ht
generally been fine.
Stephen
On 10 July 2018 at 18:00, Rob Tompkins wrote:
>
>
>> On Jul 10, 2018, at 12:53 PM, Stephen Colebourne
>> wrote:
>>
>> Look at Joda-Convert/Joda-Parent for example. A Java 6 project that
>> builds on Java 8 or later, and has a module-i
Spamming multiple open source projects with the same question is not
appropriate behaviour for a company. Open source does not have
"support". Its up to users to try the code, see if it works and report
issues. Please cease and desist your spamming.
Stephen
On 17 August 2018 at 08:37, Dragan, Krz
What I would love to see it a release of commons-math 3 with an
Automatic-Module-Name for Java 9 modules (potentially the only
change). You could use the release as a way of advertising the
progress towards v4.
Stephen
On Thu, 30 Aug 2018 at 19:16, Gilles wrote:
>
> On Thu, 30 Aug 2018 07:35:12
As the author of the blog and term VALJO, here are some comments on Fraction:
You should use `of()` (overloading allowed) when the factory normally succeeds.
You should use `from` (overloading allowed) when the factory methods
are performing a conversion and have a reasonable chance of failure.
T
I think this has already been worked out, but the main reason for no
inheritance is that is probably blocks future conversion to value types.
Composition instead of inheritance is usually the right solution.
Stephen
On Sun, 9 Dec 2018 at 10:21, Gilles wrote:
> Hello.
>
> After the discussion q
um, you get flexible behaviour
without subclass.
Stephen
On Wed, 12 Dec 2018 at 23:20, Gilles wrote:
> Hi.
>
> On Wed, 12 Dec 2018 22:48:54 +, Stephen Colebourne wrote:
> > I think this has already been worked out, but the main reason for no
> > inheritance is that is p
I'd suggest `of` and `ofXxx` for factories that perform little work,
such as assigning to instance fields, and `from` and `fromXxx` for
factories that perform meaningful work or conversion.
Stephen
On Fri, 28 Dec 2018 at 17:24, Eric Barnhill wrote:
>
> Fractions are constructed using either int
Hi All,
Java 9 is coming soon (unless it is delayed again, but that seems
unlikely). The major feature is JPMS, the Java Platform Module System.
While JPMS is far from ideal, projects like Apache Commons and mine
Joda-* are going to be key to getting some adoption. This is
particularly true as Comm
lang3.time;
exports org.apache.commons.lang3.tuple;
}
Stephen
On 21 April 2017 at 13:31, Emmanuel Bourg wrote:
> Le 21/04/2017 à 14:00, Stephen Colebourne a écrit :
>
>> Comments? Questions?
>
> Hi Stephen,
>
> Thank you for stopping by and enlightening us about JPMS. The n
On 21 April 2017 at 13:59, sebb wrote:
> What happens when there is a API break which necessitates a package name
> change?
> I assume that the module name will also need to change to the new
> super-package.
> e.g.
>
> Commons-Lang4
> -> super-package org.apache.commons.lang4
> -> module org.ap
.logging.log4j.core.
> These obviously overlap. Most of our other jars have packages that are in
> org.apache.logging.log4j.xxx where xxx matches the jar name. We aren’t going
> to change the API to support modules.
>
> Is there some reasonable way around this?
>
> Ralph
&
ommons.lang3.reflect;
> exports org.apache.commons.lang3.text;
> exports org.apache.commons.lang3.text.translate;
> exports org.apache.commons.lang3.time;
> exports org.apache.commons.lang3.tuple;
> }
>
> Stephen
>
> On 21 April 2017 at 13:31, Emmanuel Bourg wrote:
>> L
n’t yet been modularized? Normally I would expect to have requires
> directives.
>
> Ralph
>
>> On Apr 21, 2017, at 6:04 PM, Ralph Goers wrote:
>>
>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure
>> to submit a PR when I get somethin
On 22 April 2017 at 05:18, Matt Sicker wrote:
> Despite all the shit the Java champions talk about OSGi, Jigsaw is still a
> simplified version of OSGi basically, so anything already supported via
> OSGi will generally port extremely easily to Java 9 modules.
JPMS (Jigsaw) is not a simplified OSG
On 22 April 2017 at 09:00, Emmanuel Bourg wrote:
> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
>> I've started a page here:
>> https://github.com/jodastephen/jpms-module-names/blob/master/README.md
>> Feel free to raise a PR with more projects at commons or el
ule system support Maven’s runtime scope?
>
> Ralph
>
>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne
>> wrote:
>>
>> See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and
>> https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-a
but is required to run. It appears I have to
> convert my runtime scopes to compile in order to get the module to compile
> and build properly.
>
> That sucks.
>
> Sent from my iPhone
>
>> On Apr 23, 2017, at 7:43 AM, Stephen Colebourne wrote:
>>
>> I
On 24 April 2017 at 11:08, Jörg Schaible wrote:
> Stephen Colebourne wrote:
>
>> Sounds like you could use --add-modules to add the module separately
>> from the command line, or add the module to the application's
>> module-info rather than the libraries.
>>
Not sure when the next planned release is, but it might be worth
adding the proposed entry in MANIFEST.MF for modules. It isn't
guaranteed to be in the final JDK 9, but my best guess is that it
won't change now. It would involve making a pom.xml change to add this
to the manifest:
Automatic-Module
On 17 May 2017 at 21:44, Benedikt Ritter wrote:
>> Automatic-Module-Name: org.apache.commons.lang3
>>
>> This allows other projects to safely depend on [lang3]. Ultimately,
>> we'll have to add a module-info, but this is a much simpler first
>> step.
>
> It’s nice to see you being more active at C
Is reusing ${commons.osgi.symbolicName} a good idea?
It seems to me that each project should have to opt-in to this
attribute, so I'd add a new ${commons.automatic.moduile.name}
variable.
One reason is that the attribute should only be added if the project
is suitable for use as a module (eg. no p
On 22 May 2017 at 00:32, Benedikt Ritter wrote:
> This is not as straight forward as I thought. Simply adding
>
> ${commons.automatic-module-name}
>
> Does not work, since this will add an empty entry to the resulting manifest
> file, if a component does not specify the commons.automatic-module-n
On 22 May 2017 at 12:51, Rob Tompkins wrote:
> You could, in the parent, declare in the properties section beside the
> declaration of “commons.osgi.symbolicName”, another property pointing to that
> as
>
> ${commons.osgi.symbolicName}
>
> and then allow people to override that in their local po
I took a stab at adding module-info.java to [lang]:
https://github.com/jodastephen/commons-lang/commit/5d5dd6809eeef90ea2b6245c0d0a488fb917e30a
Since the maven-bundle-plugin isn't working, I had to use antrun to
copy the module-info.class file out and back in again. A gross hack.
There are two ke
On 22 May 2017 at 23:29, Gary Gregory wrote:
> Don't you mean 4.0 since changing:
>
> - AbstractCircuitBreaker.addChangeListener(PropertyChangeListener)
> - AbstractCircuitBreaker.removeChangeListener(PropertyChangeListener)
>
> would break BC?
No. I meant 3.7. [lang] has a problem with versionin
On 23 May 2017 at 10:13, Jochen Wiedmann wrote:
> I am -0 to -1 regarding the introduction of new components. I'd rather
> see us redefine the purpose of commons-lang. The experience of
> commons-math has demonstrated, IMO, that such new components will most
> likely increase the noise without an
On 22 May 2017 at 00:56, Benedikt Ritter wrote:
> I think the time has come to start thinking about Lang 4.0.
As I outlined in another thread, Lang 3.5 uses PropertyChangeListener,
which in module terms pulls in the whole of Swing and AWT. For a
library like [lang] that is a bad thing and should
On 23 May 2017 at 11:54, sebb wrote:
>> Fixing it properly requires a major release, which implies that Lang
>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
>> package name.
>
> I think that depends on whether the API is backwards-compatible or not.
>
> If it *is* backwards-
On 23 May 2017 at 16:07, sebb wrote:
> Huh?
>
> The whole point of changing the package name and Maven coords is to
> allow mutually incompatible jars to coexist peacefully on a single
> classpath.
All you are doing in replacing one kind of jar hell with another.
Removing these methods means tha
On 23 May 2017 at 17:17, sebb wrote:
>> Yes, the
>> code compiles and both can be on the classpath, but it is a pain to
>> use, just a different kind of hell.
>
> I don't see what the problem is here.
Library A that depends on lang3 returns a Pair.
Library B that depends on lang4 takes a Pair.
Ap
On 24 May 2017 at 15:55, Rob Tompkins wrote:
> We should simply add that entry, "commons.automatic-module-name," to every
> component pom’s properties section now, and then when the next parent
> migration happens, the changes will express naturally. It might be worth
> adding a comment on the
On 25 May 2017 at 17:23, Oliver Heger wrote:
> I also think that a new major release just to fix this problem would be
> overkill and cause clients even more trouble.
>
> Would the following approach work as a compromise:
>
> - [lang] declares an optional dependency to the desktop module.
> - All
On 5 June 2017 at 09:35, Benedikt Ritter wrote:
> Is there some documentation on how to check validity?
I'm sure there is info in various places, but I've not seen a checklist.
Off the top of my head:
- all packages under a single super-package that is the module name
- jdeps shows no use of int
This looks fine in terms of what it does. Obviously not ideal to have
the copying, but that is the right choice to make right now.
Stephen
On 7 June 2017 at 09:25, Benedikt Ritter wrote:
> Hi,
>
> here [1] is my proposal on how to add the Automatic-Module-Name entry to
> MANIFEST. This just dup
I didn't get the chance to reply when this thread happened, but really
a project should only be viewed as JDK 9 ready when it has had a
release with the Automatic-Module-Name entry in the manifest file.
AFAIK, only common-lang has this (Although commons-csv, email and jcs
were released recently I d
nt POM and releasing that POM first?
>
> Stephen Colebourne said that we have to check on a per component basis
> whether the component is ready to be released as Java 9 module. For this
> reason we wanted to add this to every component individually. At least that
> is what I recall.
&g
On 20 September 2017 at 17:21, Matt Benson wrote:
> On Sep 20, 2017 11:08 AM, "Stephen Colebourne" wrote:
>
> I think its worth the extra step of checking the conditions are right
> for adding the Automatic-Module-Name manifest entry.
>
>
> Wouldn't that j
On 20 September 2017 at 17:12, Benedikt Ritter wrote:
>> Von: Stephen Colebourne
>> I've not got maven to work with actual module-info.java files yet on
>> the Joda projects, but they are a more complex setup. Maybe
>> [collections] could be the first to get a real
On 26 September 2017 at 16:06, Benedikt Ritter wrote:
> commons-logging.jar
> commons-logging-adapters.jar
> commons-logging-api.jar
>
> All jars have org.apache.commons.logging as root package, so if I understand
> correctly we can’t do the Automatic-Module-Name trick, because this would
> requ
On 26 September 2017 at 18:48, Jörg Schaible wrote:
> AFAICS we have only commons-logging. The other artifacts have not been part
> of any release in the last decade.
Simple then!
Stephen
-
To unsubscribe, e-mail: dev-unsubscr..
ntral. (In fact, why not
just delete their creation in pom.xml ?)
Stephen
On 26 September 2017 at 22:05, Benedikt Ritter wrote:
>
>> Am 26.09.2017 um 22:54 schrieb Stephen Colebourne :
>>
>> On 26 September 2017 at 18:48, Jörg Schaible wrote:
>>> AFAICS we have only c
On 27 September 2017 at 00:01, Emmanuel Bourg wrote:
> I wonder if we should do the same for commons-lang 2.x, it's still
> commonly used.
Yes. This would be very helpful
Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@commons
On 1 October 2017 at 11:34, Stefan Bodewig wrote:
> - only add the automatic module name to commons-logging and release api
> and adapter as they are.
Exactly. This is the right approach.
Stephen
-
To unsubscribe, e-mail: dev-un
Looks good AFAICT
Stephen
On 9 October 2017 at 14:39, Emmanuel Bourg wrote:
> Le 29/09/2017 à 10:08, Emmanuel Bourg a écrit :
>
>> I'd like to prepare a new release of Commons Lang 2 that addresses the
>> Java 9 compatibility. I have two items in mind for this update, the
>> automatic module name
On 14 October 2017 at 14:05, Rob Tompkins wrote:
>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter wrote:
> Feels like a change that would warrant a major version change, but that would
> have us maintaining another major version branch.
No need for a major version change. Its just one more .clas
t;>>> The last time I tried to use Log4j 2 (which contains Java 9 classes files
>>>> in the right multi-jar spot) with an Android app, the Android tooling
>>> threw
>>>> up all over itself because it was incorrectly trying to do something with
>>>> t
On 16 October 2017 at 14:14, Simon Spero wrote:
> [In regards to original question, -0.0 (harmless, but pointless, since
> applications should not use lang as a jpms module.
Huh? Of course they should.
> To be usable as a jpms
> module, EVERY release that has ANY api change must use new module
See latest changes.
https://github.com/apache/commons-lang/pull/299/files
https://travis-ci.org/apache/commons-lang/builds/289148663
It now builds on Java 7, 8 and 9, varying what it does on each JDK.
Releases will need to be on Java 9 for the jar file, but 8 for the
site plugin if I understand
g the default goal of the pom ("mvn clean verify
> apache-rat:check clirr:check checkstyle:check findbugs:check
> javadoc:javadoc")
>
> It would be nice if you could update the pull request, so that we do not
> lose these additional automated checks.
>
> Thank
Just to note that there is no Automatic-Module-Name in the MANIFEST
On 25 October 2017 at 04:19, Gary Gregory wrote:
> We have fixed a few bugs since Apache Commons Pool 2.4.2 was released, so I
> would like to release Apache Commons Pool 2.4.3.
>
> Apache Commons Pool 2.4.3 RC1 is available for
On 31 December 2011 08:45, Henri Yandell wrote:
> Three changes of interest. Two are the removal of final on public
> methods. The other is the addition of Serializable to StrBuilder.
As described above, those are source and binary compatible.
Stephen
> Which is the worry? And is it a big enou
On 4 February 2012 05:38, ma...@nimp.co.uk wrote:
> Apache Commons Lang seems to be the right place for that kind of utility
> class, however, my utility class is coded in Scala, is that ok ?
Not in my opinion No.
I have no problem with a Scala-only commons component, but I think
mixing two lang
On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
Sebb, someone needs to check to see if any collections in
[collections] could implement the new interfaces added in Java 6 -
NavigableSet, NavigableMap and so on.
Stephen
On 24 June 2012 12:25, sebb wrote:
> On 24 June 2012
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Wed, Jul 4, 2012 at 9:59 AM, Jörg Schaible
>> wrote:
>>> Stephen Colebourne wrote:
>>>
>>>> On Java 5/6, I'
Essentially, a more valid version is in [configuration] IIRC, but this
one remained because people didn't want to load another jar just for
this "simple functaionlity". All IIRC.
Stephen
On 20 October 2010 16:32, Matt Benson wrote:
>
> On Oct 19, 2010, at 9:29 PM, sebb wrote:
>
>> IMO, the Exte
While I hardly count as having a vote now, I do have an opinion ;-)
I think that the formulation below is too strong. I'd argue that
changing the package name is required when there is significant
incompatibility, but a major version change might not cause such
incompatibility.
For example, if a
On 25 November 2010 12:01, Niall Pemberton wrote:
>
> IMO changing the package name is always a bad idea and I think we have
> been too quick to do it, rather than trying to retain compatibility.
> Its effectively starting a new component and perhaps merited on rare
> occasions - but I think we h
I would see this as more like caching functionality than collections
functionality. And there are plenty of other caching libraries.
Stephen
On 13 December 2010 03:27, Balazs Attila-Mihaly (Cd-MaN)
wrote:
> Hello everybody.
>
> I would like to know if there would be any interest of including a
I would recommend against this for [lang].
[lang] is a low-level project intended to have no framework or
"religious" aspects, just simple relatively non-controversial elements
that assist the basic Java packages. A maths parser, however useful,
isn't that closely related IMO.
Stephen
On 5 Janu
On 27 January 2011 08:45, Jörg Schaible wrote:
> In the light of LANG-577, I wondered if the mutable package is still
> necessary looking at the concurrent stuff of the JDK. I tried once to start
> a discussion about it
> (http://article.gmane.org/gmane.comp.jakarta.commons.devel/112282), but got
Traditionally, many commons projects has taken no position on the
correct way to instantiate objects, whether via constructor or bean
methods. This was to allow construction from tools such as Velocity.
It is also still easier to construct using Spring via bean methods
rather than the constructor.
>
>>> On Sat, Jan 29, 2011 at 2:33 PM, Jacopo Cappellato
>>> wrote:
>>>> Thank you Stephen,
>>>>
>>>> I understand this; alternatively we could implement a factory method that
>>>> clones DEFAULT_STRATEGY, EXCEL_STRATEGY, TDF_S
It used to be dubious practice, but now that IDEs can provide an error
for this case, it is IMO back to being good practice (in that its easy
to read and understand, and follows the Sun conventions)
Stephen
On 30 January 2011 13:22, Mikkel Meyer Andersen wrote:
> Hi,
>
> I noticed that you have c
On 30 January 2011 15:11, sebb wrote:
> On 30 January 2011 09:09, Stephen Colebourne wrote:
>> The modern standard for altering immutable classes was laid down by Joda-Time
>>
>> strategy = strategy.withCommentStart("#");
>
> Not sure I undestand that.
A
I have no philosophical problem with adding to an enum in a later
release, its designed to be compatible (don't persist the ordinal).
However, I'm unconvinced that an enum is the right solution here. I
should probably study the details, but if Android is broken perhaps
thats just how it is.
Stephen
I can give some feedback based on JSR-310.
I have a small hierarchy of exceptions that attempts to capture some
key problems that may occur. The problem I found was that as I
refactored code, the exceptions listed in Javadoc quickly became
inaccurate. As a result, I've started converting many exce
On 1 February 2011 13:52, wrote:
>> I have a small hierarchy of exceptions that attempts to capture some
>> key problems that may occur. The problem I found was that as I
>> refactored code, the exceptions listed in Javadoc quickly became
>> inaccurate. As a result, I've started converting many e
On 2 February 2011 00:12, Gilles Sadowski wrote:
>> Here is a probably too simple example:
>>
>> com.example defines IOException
>> com.example.input uses IOException
>> com.example.output uses IOException
>
> Well, I don't see that as obviously better than storing all exceptions in an
> "exceptio
On 2 February 2011 06:04, Phil Steitz wrote:
> What we report back to the application using [math] is that one of
> the following kinds of bad things has happened
>
> a) they have violated preconditions - they get
> MathIllegalArgumentException (same semantics as anywhere else)
> b) they have not
On 2 February 2011 09:23, Luc Maisonobe wrote:
> It seems the thread asking for help on the exception API design is going
> to be fruitful, and it starts well with interesting ideas. I guess some
> of these ideas will change again our view and we will converge
> (hopefully not throwing an exceptio
Apache is a place where community matters more than code. Right now,
the community dynamics within [math] are clearly difficult.
I ask ALL those involved to step back for the weekend and to not post
on the topic of [math] until Monday.
In that time, I ask ALL involved to reflect on how the situat
Based on what I know of OGNL, it is/was reasonably well used. Trying
to merge it into another project doesn't help those existing users.
The question is what are the author(s) of OGNL looking for? A home for
maintainance? The Apache brand? To reinvigorate it? The latter fits
with a merger into oth
The recognised standard in the JDK is NPE on invalid null input.
I have never overly liked this, but conform to it for JSR-310/ThreeTen.
I use IAE in other projects which are higher up the stack. Whether
[math] is low or high level may determine the choice you make.
Personally, I don't use NullA
I consider it sufficient (preferable) to do the following:
@param foo the foo, not null
Where the ", not null" implies NPE when a null is passed in (document
once in the overview javadoc if you feel necessary). This approach is
easier to transfer to a @NotNull annotation in the future (or the
pro
To be a TLP, you need a bare minimum of 3 active committers,
preferably 6. And you'd need to go via the incubator. Commons is an
easier fit as the committers can be shared with other commons
components, but that still depends on existing commons committers
saying that they'd be willing to help supp
I'm not overly enthused about some of the changes, but since I've not
been paying attention its difficult for me to vote/block. Anyway here
is my review:
ArrayUtils.hashCode() has been removed, but it had different
functionality to Arrays.hashCode wrt nested arrays.
Object[] arrayA = new
1 - 100 of 253 matches
Mail list logo
