| Time |
S |
Nick |
Message |
| 00:21 |
|
|
SoniEx2|2 joined ##javaee |
| 01:04 |
|
|
pdurbin joined ##javaee |
| 01:20 |
|
|
SoniEx2|2 joined ##javaee |
| 01:20 |
|
|
sfisque joined ##javaee |
| 01:21 |
|
|
sfisque1 joined ##javaee |
| 01:15 |
|
|
philbot joined ##javaee |
| 01:15 |
|
|
Topic for ##javaee is now Java (general & all kinds of) and Java Enterprise Edition (Java EE) discussion. | logs at http://irclog.greptilian.com/javaee/today. We are a bit more friendly, you may keep silence as a response but you have no right to insult/abuse a person in any case. |
| 01:16 |
|
|
Topic for ##javaee is now Java Enterprise Edition (Java EE) discussion | logs at http://irclog.greptilian.com/javaee/today |
| 02:03 |
|
|
caverdude joined ##javaee |
| 02:20 |
|
|
SoniEx2|2 joined ##javaee |
| 03:11 |
|
|
Naros joined ##javaee |
| 03:21 |
|
|
SoniEx2|2 joined ##javaee |
| 04:20 |
|
|
SoniEx2|2 joined ##javaee |
| 04:38 |
|
|
Quest joined ##javaee |
| 04:54 |
|
|
caverdude joined ##javaee |
| 05:05 |
|
caverdude |
good evening |
| 05:21 |
|
|
SoniEx2|2 joined ##javaee |
| 06:20 |
|
|
SoniEx2|2 joined ##javaee |
| 06:21 |
|
Guest30924 |
caverdude, hi |
| 09:20 |
|
|
SoniEx2|2 joined ##javaee |
| 10:21 |
|
|
SoniEx2|2 joined ##javaee |
| 11:21 |
|
|
SoniEx2|2 joined ##javaee |
| 12:07 |
|
|
Guest30924 joined ##javaee |
| 13:17 |
|
|
Naros joined ##javaee |
| 13:25 |
|
|
Quest joined ##javaee |
| 13:55 |
|
|
Guest15027 joined ##javaee |
| 14:17 |
|
Naros |
sfisque: got time for what I hope is a quick question? |
| 14:18 |
|
Naros |
I am trying to decouple one of my package circular dependencies and I can't seem to find a good logical way to do it. |
| 14:19 |
|
Naros |
We have a business concept that acts somewhat like a security constraint to some degree, but it isn't a constraint that prevents seeing a record, but only portions of a given record, mainly around cost. |
| 14:20 |
|
|
SoniEx2|2 joined ##javaee |
| 14:21 |
|
Naros |
So we assign a code and this code is then associated to various records throughout purchasing, inventory, reporting, pretty much the entire technology stack. |
| 14:21 |
|
Naros |
One idea was to put this business concept near the bottom of the dependency graph. |
| 14:22 |
|
Naros |
core <- businses concept <- inventory <- purchasing <- maintenance <- reporting |
| 14:22 |
|
Naros |
but I've been trying to put it "core <- inv <- purchasing <- maint <- reporting <- concept" |
| 14:23 |
|
Naros |
and where that breaks down is that what if I want to get a list of items from inv based on this business concept code. If its at the top of the graph, the only way to avoid the dependency would be to use some interface and implement it at the higher level |
| 14:24 |
|
Naros |
but that would in turn limit the data one could obtain at the lower graph levels. |
| 14:24 |
|
Naros |
so idk |
| 14:38 |
|
Naros |
I think I'll move this business concept to a lower level in the dependency graph and then move some of the models into their respective purchasing/inventory modules being based on the lower dependency package. |
| 14:49 |
|
sfisque |
if it's that pervasive, then the data that it relies on is probably meta-data (security codes? permission codes?) that being said, i'd decouple around an interface that is in a centralized package (core? util?) and then the concrete realizations can reside anywhere in the API as long as they fulfill the contracts of the interfaces |
| 14:50 |
|
Naros |
OK, I'll look into that approach too. |
| 14:52 |
|
sfisque |
if the objects are not "managed beans" (cdi/ejb) (assuming you're not using spring) you can always decouple further via @Produces injection points |
| 14:53 |
|
sfisque |
i guess i should say "@Produces injectOR points" |
| 14:54 |
|
Naros |
lol yah i knew what u meant |
| 14:54 |
|
sfisque |
well, time for me to commute. ttys.. code strong! |
| 15:21 |
|
|
SoniEx2|2 joined ##javaee |
| 15:46 |
|
|
sfisque joined ##javaee |
| 16:09 |
|
|
kobain joined ##javaee |
| 16:21 |
|
|
SoniEx2|2 joined ##javaee |
| 17:20 |
|
|
SoniEx2|2 joined ##javaee |
| 18:20 |
|
|
SoniEx2|2 joined ##javaee |
| 18:24 |
|
|
whartung joined ##javaee |
| 19:20 |
|
|
SoniEx2|2 joined ##javaee |
| 20:41 |
|
|
sfisque joined ##javaee |
| 20:41 |
|
|
sfisque1 joined ##javaee |
| 22:20 |
|
|
SoniEx2|2 joined ##javaee |
| 23:33 |
|
SoniEx2 |
ok ##java isn't very... friendly... so... |
| 23:33 |
|
SoniEx2 |
how can I read PNGs efficiently? |
| 23:35 |
|
whartung |
Dunno. javax.imageio? |
| 23:35 |
|
whartung |
no, ##Java isn't friendly at all. I don't go there. |
| 23:35 |
|
SoniEx2 |
well PNG-like files that aren't really PNG |
| 23:35 |
|
SoniEx2 |
this should help: https://github.com/SoniEx2/NBX-API/tree/master/src/com/github/soniex2/nbx/api/stream |
| 23:35 |
|
whartung |
what does PNG-like mean? |
| 23:36 |
|
whartung |
I don't know what I'm looking at there |
| 23:36 |
|
whartung |
and what do you mean by "efficiently"? |
| 23:37 |
|
SoniEx2 |
well NBX is basically little-endian PNG |
| 23:37 |
|
SoniEx2 |
and I mean buffered |
| 23:38 |
|
whartung |
what's wrong with a BufferedInputStream? |
| 23:39 |
|
SoniEx2 |
I'm already using that |
| 23:40 |
|
whartung |
I/O wise, you're likely not going to get any faster than that, assuming a pure sequential read. |
